Koen Claessen <[EMAIL PROTECTED]> writes:
> Alastair <[EMAIL PROTECTED]> writes:
> | 2) Don't change any code but widely advertise the fact that we don't
> | guarantee any kind of fairness and that it is the programmers'
> | responsibility to write code in a way that makes no assumptions
> | about scheduling policy.
>
> If you choose this, then it never makes sense having two processes reading
> and writing the same MVar. Isn't that the essence of MVar's? To allow
> safe _sharing_?
It is possible (and safe) to have several processes writing to an MVar
and also to have a disjoint set of processes reading from an MVar.
This is fine for many producer-consumer styles of concurrency such as
that used in my "Budget combinators" (a "cheap implementation of
Fudgets").
It is much less safe to have several processes both reading from and
writing to a single MVar if you require a non-trivial interleaving of
access and are not willing to implement your own scheduling primitives
(in the manner outlines in the Concurrent Haskell paper).
The correctness of your program seems to require the following two
properties of Concurrent Haskell (taken from the Concurrent Haskell
paper):
i) No runnable process will be indefinitely delayed.
ii) No process can be blocked indefinitely on an MVar unless another
process holds that MVar indefinitely.
Hugs does not satisfy property (i) and there is no easy fix.
Hugs does not currently satisfy property (ii). Your fix will solve
the problem but without property (i) this property is useless. For
example, you could imagine a process schedule where each process was
indefinitely delayed if it was _about to_ block on an MVar unless
there were no other runnable proceses.
If you can think of a set of properties which satisfy these requirements
then I'll be glad to make the changes.
1) Are _weaker_ than the properties of Concurrent Haskell.
(We can't easily make them as strong and having incomparable
properties encourages the creation of programs which will not
run on GHC.)
2) Require minimal changes to Hugs.
3) Are strong enough to prove useful properties of a wider range of
programs (including your example).
Since I can't think of a set of properties satisfying this
requirement, I'll settle for the following (very weak) property which
satisfies the first 2 requirements.
Execution continues until one of the following occurs:
1) All processes are blocked on MVars.
2) A process aborts (either enters _!_, executes "exitWith"
or raises an uncaught IOError).
--
Alastair Reid Yale Haskell Project Hacker
[EMAIL PROTECTED] http://WWW.CS.Yale.EDU/homes/reid-alastair/
