question about concurrency implementation

[Simon Marlow]

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

"yes"

> If the costs are the same, does that rely on there being no true=20
> 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