Concurrency (was: RE: Re[2]: important news: refocusing discussion)

[Manuel M T Chakravarty]

Malcolm Wallace:
> "Simon Marlow" <simonmar at microsoft.com> wrote:
> 
> >  (a) we're going to standardise concurrency anyway
> 
> Well, but that only begs the question, what *kind* of concurrency are we
> going to standardise on?  e.g. Will we admit all variations of scheduling
> (co-operative, time-slice, and pre-emptive)?
> 
> >  (b) it is unlikely that Hugs or JHC will implement concurrency
> >      even if it goes into the standard
> 
> Now this is something that puzzles me.  I was under the impression that
> Hugs already implements concurrency, using pretty much the same APIs as
> ghc.

Hugs implements (part of?) the API, but it only implements purely
co-operative concurrency (ie, thread switches only happen when
Concurrency operations, such as takeMVar, are invoked).

> > Yes there are several ramifications of this decision, but none of them
> > are technical.  As I see it, we either specify Concurrency as an
> > addendum, or NoConcurrency as an addendum, and both options are about
> > the same amount of work.
> 
> 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?

Because Hugs only supports co-operative scheduling.  IANAJE[*] but I
think that this is what Java did and regretted.  It means that
"standards conforming" concurrent programs have to work under all
scheduling models allowed by the standard (if they want to be portable),
which means there won't be many such programs - which in turn defeats
the purpose of the exercise.

In other words, if the standard is not restricting the admissible
behaviour of implementations sufficiently, its going to be hard to write
many useful programs against the standard.

Manuel

[*] I Am Not a Java Expert