[Haskell-cafe] semantics of concurrent program depends on -O level, -f[no-]omit-yields

[Sven Panne]

Am Do., 29. Nov. 2018 um 21:54 Uhr schrieb Ian Denhardt <ian at zenhack.net>:

> [...] I've been able to reproduce your results, and if I change the last
> line
> to:
>
>     forever $ do
>         yield
>         atomically $ writeTVar x True
>
> ..it always prints -- so the culprit is definitely a failure to yield.
>

But even that is not enough from a specification POV: After the yield, the
same thread might be schedule immediately again, and again, ... Or do we
have some specification of the scheduler? I don't think so, but perhaps I'm
wrong in this respect. If we have one, it has to state explicitly that the
scheduling is fair in the sense that every runnable thread actually runs
after a finite amount of time, otherwise you are in undefined land again...

The question where scheduling can actually happen is a totally different
issue, and I don't know of a specification here, either. In GHC, this seems
to be tied to allocations, but this is a bit brittle and unintuitive. To
guarantee that you hit a scheduling point after a finite amount of time is
easy in principle, e.g. do this on every backwards branch and on every
function entry. But this has an associated cost, so we have a tradeoff here.

In general, I wouldn't worry too much about the semantics of unsynchronized
threads, if you rely on this somehow, you will sooner or later enter a
world of pain. Add e.g. thread priorities to the mix, and you will suffer
even more, experiencing wonderful things like priority inversion etc.  :-P
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20181130/28815666/attachment.html>