question about concurrency implementation

Phil Trinder
Wed, 20 Mar 2002 11:51:57 +0000 (GMT Standard Time)


> > 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.

We've developed a Haskell extension that exhibit's "true concurrency" on 
multiple CPUs, it's called Glasgow distributed Haskell (GdH). It's primarily 
designed for distribution (i.e. multiple stateful threads on multiple 
processors), but can be used to build parallel programs too. For more info see


Phil Trinder
Department of Computing and Electrical Engineering
Heriot Watt University
Edinburgh, EH14 4AS

Teleph: +44 (0)131 451 3435
Depart: +44 (0)131 451 3328
Fasmly: +44 (0)131 451 3327