The goals of the concurrency standard?

[Simon Marlow]

On 12 April 2006 11:03, John Meacham wrote:

> On Wed, Apr 12, 2006 at 10:24:57AM +0100, Simon Marlow wrote:
>> On 12 April 2006 08:41, John Meacham wrote:
>> 
>>> However, I am also of the mind that preemtiveness alone doesn't buy
>>> enough to make the runtime cost of locking worth it which is why I
>>> plan for jhc to be fully cooperative or fully OS threaded with no
>>> middle ground. but the situation is different in compilers such as
>>> nhc, where preemptiveness can be added relatively easily due to its
>>> run-time design and absolute speed was never a goal. In any case,
>>> the standard should admit a range of implementations.
>> 
>> Couldn't pre-emption be implemented quite easily in JHC if you
>> compiled to C--?  And imprecise exceptions, for that matter.
> 
> no, it doesn't really help, the main things C-- provides over C are
> continuations and the introspection into the stack needed for garbage
> collection. everything c-- continuations would be useful for I am
> already using longjmp and setjmp for for cooperative concurrency.
> mainly jumping between multiple C stacks (which are the same as
> haskell stacks).
> 
> the issues facing a preemptive implemenentation are that
> there is no way to implement black-holing, multiple threads will
> happily waste time evaluating the same thunk, but worse, updates would
> have to be protected by some sort of mutex or lock. jhc updates nodes
> in place, meaning a single atomic write to an indirection can't be
> used, to avoid a context switch in the middle of an update, either
> locks need to be placed around it, or run-time checks need to be made
> at safe points (which is arguably not much different than cooperative
> scheduling). 

I'll argue that point :)  GHC makes run-time checks at safe points and
implements preemptive concurrency.  Cooperative scheduling is when the
*programmer* has to insert the safe points.

The safe points don't even have to be very often: in GHC the context
switch check is made after every 4k of allocation.

Point taken about black holes.

Cheers,
	Simon