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

John Meacham john at repetae.net
Wed Mar 29 06:35:06 EST 2006


On Wed, Mar 29, 2006 at 11:44:12AM +0100, Simon Marlow wrote:
> Let's stick to fairness.  These are the requirements I think the
> standard should include:
> 
>    No runnable process will be indefinitely delayed.
> 
>    No thread can be blocked indefinitely on an MVar unless another
>    thread holds the MVar indefinitely.
> 
>    Suitably annotated foreign calls run concurrently
>    with other Haskell threads.
> 
> That does preclude a cooperative implementation, and for good reasons.
> Manuel made the point that if a cooperative implementation is admitted
> by the standard, that makes it much harder to write portable concurrent
> code.  Code written using GHC wouldn't neceessarily run properly on a
> cooperative implementation, despite the fact that both implementations
> would be conforming.  I think Haskell' should avoid this pitfall.

I don't think we should preclude cooperative implementations. inserting
extra yields is harmless, omitting them when needed is bad. That and
relying on the implementation for preemption is just asking for trouble
in general. neither pthreads or java make such strong fairness
guarentees.

I would prefer a much weaker 'progress guarentee'

 * if any haskell thread is runable, at least one will be running.
 * a succession of yields will cycle through all runable threads in a
   finite number of steps.
 * these rules will still apply reguardless of whether suitably
   annotated foreign calls are running.

it is much easier to program to and understand.

I mean, if an implementation allocates 1 out of every thousand cycles to
thread a as opposed to b, then it is still 'fair' by the above rules,
but you would certainly want to take that into account when writing your
program. Programs written as if they were running on a cooperative
system will be more portable and more likely to work out of the box on
alternate implementations than they were tested on.

I am not sure what the MVar guarentee means, if it is blocked on an
MVar, then it becomes runnable when the MVar is filled, so the runnable
rule seems to take care of it.

        John


-- 
John Meacham - ⑆repetae.net⑆john⑈


More information about the Haskell-prime mailing list