> 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 [EMAIL PROTECTED] http://www.cs.utah.edu/~reid/ _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell