The goals of the concurrency standard?

[John Meacham]

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 am not saying these problems arn't solvable, I just think for jhc's
goals preemtive scheduling just doesn't seem worth the runtime or
implementation cost. I'd rather make the jump to full OS-threads which
has some interesting problems I look forward to working on at some
point.

In any case, even if preemptive scheduling were easy, I wouldn't
want the standard to require it, at it does put a fairly large burden on
the implementor, and as oleg was pointing out, programmers can write
code that blocks things no matter what the implementation method.

        John

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