I'm curious about the implementation of Concurrent Haskell in GHC and Hugs. 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.
"yes"
If the costs are the same, does that rely on there being no true concurrency in the current implementations?
It depends what you mean by true concurrency: from the point of view of the Haskell programmer, GHC's implementation of concurrency is "almost" preemptive, because we can context-switch at any allocation. Most computation does some allocation, but it's possible to write functions that don't (although these tend to be on the trivial side - an optimised nfib won't allocate, for example). We could artificially cause all computation to do some allocation to avoid this problem, but we haven't found it necessary so far. But I suspect by "true concurrency" you're referring at the kind of concurrent processes that can be executed on multiple CPUs simultaneously. We did investigate doing this a while back, and found that the locking required on thunks was very expensive (slowed down the program by at least 2x on the bog-standard SMP machine we had here). However there are some clever techniques that can be used to reduce the cost - giving each process its own private allocation area and only degrading to full locking for access to the shared portion of the heap is one such technique we experimented with briefly but I don't have any concrete benchmarks I'm afraid. Also you really need a multithreaded garbage collector, which is a lot of work. Cheers, Simon