question about concurrency implementation

[Alastair David Reid]

> I'm curious about the implementation of Concurrent Haskell in GHC
> and Hugs.

Hugs' implementation of concurrency is non-preemptive wherease GHC's
implementation is preemptive (or "almost preemptive") as described by
Simon.

> Does access to values possibly shared among threads cost the same in
> Concurrent Haskell as in regular Haskell?  I'm guessing the answer
> is "yes", because Concurrent Haskell is provided by default in GHC.

The answer is yes for Hugs.

> If the costs are the same, does that rely on there being no true
> concurrency in the current implementations? 

Just to be sure we agree on terminology: some people like to
distinguish between "parallelism" and "concurrency".

Parallelism is a way of going faster but doesn't change your
programming model.  Implemented correctly, a parallel implementation
yields the same results as a sequential implementation - it just runs
faster.  (This is ignoring the effects of interaction with the outside
world, of course - since that can also affect determinism.)  Parallel
Haskell adds "par" and friends (operations which have no effect on the
semantics of your program).

Concurrency changes your programming model.  A concurrent program is
allowed to give different results and interesting interactions
(including race conditions) between threads.  A concurrent program may
run on a single processor.  Concurrent Haskell adds forkIO,
killThread, MVars, etc (operations which affect not just the semantics
of your program but also the way the semantics are defined).

You might want to use different words for those concepts but I hope
the distinction is clear.  (Note that the two concepts are rarely/never
separated in imperative languages.  Arguably, Esterel is an exception.)

Using this terminology, I think what you're asking about is
"parallelism" and not "concurrency".

-- 
Alastair Reid        reid@cs.utah.edu        http://www.cs.utah.edu/~reid/