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