Pre-emptive or co-operative concurrency (was: Concurrency)

Simon Marlow simonmar at microsoft.com
Tue Mar 28 08:43:09 EST 2006


On 28 March 2006 11:14, Malcolm Wallace wrote:

> There are certainly technical questions.  If Hugs's implementation of
> concurrency is not concurrency after all, on what basis do we make
> that determination?  Why is a definition of concurrency that
> encompasses both ghc and Hugs models unacceptable?

Ok, I'll try to nail down what we should require in terms of fairness
(which is the same as pre-emption).

The Concurrent Haskell paper [1] gives two requirements.  These are:

  No runnable process will be indefinitely delayed

  No thread can be blocked indefinitely on an MVar unless
  another thread holds the MVar indefinitely.

The spec also needs to say something about non-blocking foreign calls
and concurrent I/O.  Both are important, because one of the main uses of
concurrency is as a way of structuring a program that interacts with
asynchronous external agents.  

So I propose for the purposes of the standard/addendum, we adopt the
above definitions of fairness, together with the requirement that "safe"
(and maybe "blockable") foreign calls and I/O operations do not block
other threads.

That would mean that Hugs doesn't currently comply.  My guess is that it
could be made a lot closer than it currently is - eg. the IO monad's
bind could be made to 'yield' occasionally, non-blocking foreign calls
could be implemented, and the I/O library could be made to use them.
But this is all real work.

If you want to be really picky, GHC doesn't comply either, because a
thread can avoid pre-emption by not doing any allocation (we consider
this a bug).

Cheers,
	Simon

[1] http://www.haskell.org/ghc/docs/papers/concurrent-haskell.ps.gz


More information about the Haskell-prime mailing list