views:

217

answers:

3

In a 2005 research paper it said

Concurrent Haskell is currently implemented only for a uni-processor. The runtime schedules lightweight Haskell thread within a single operating system thread. Haskell threads are only suspended at well-defined “safe points”; they cannot be pre-empted at arbitrary moments.

Has this changed or is Concurrent Haskell still restricted to a single OS thread?

+4  A: 

GHC can use multi-cores for Concurrent and Parallel Haskell since 2004. Concurrent, Parallel, Nested Data Parallel Haskell all use the same multi-threaded runtime.

snk_kid
That link is a little unclear on the issue of STM. Do you have anything showing that Concurrent Haskell's STM functionality is compatible with its multi-core support?
Jonathan Allen
I don't think there's anything that would make it incompatible. I've certainly used STM on multiple cores.
Ganesh Sittampalam
The original impelmentation of STM was not compatible with multi-core. But since you posted your comment I've read elsewhere that it was changed to use one that would work.
Jonathan Allen
+13  A: 

[edit: the question only mentions Concurrent Haskell, but the paper referenced is, I believe, "Composable Memory Transactions", the paper in which Haskell STM was first described. Please correct me if I'm wrong here.]

STM works just fine on multiple cores now. The parallel implementation was first shipped in GHC 6.6, and uses a fine-grained two-phase locking strategy; that is, to commit a transaction the implementation first attempts to lock each variable involved in the transaction, then commits the changes, and finally unlocks all the variables. Acquiring a lock does not block: if the lock is already held, then the transaction aborts and retries (this avoids the usual lock-order-reversal deadlock that would apply if lock acquisition was blocking).

This STM implementation is certainly not the fastest - the literature describes many alternative techniques that would result in better performance, but GHC's implementation is relatively straightforward and doesn't involve any global locks (transactions operating on distinct sets of variables can proceed in parallel without interference).

Simon Marlow
+3  A: 

GHC Haskell runs well on multicores

GHC Haskell programs, since 2004, run multiple Haskell threads over multiple OS threads, which are distributed over multiple cores.

Also, you can get the latest status of multicore Haskell from this SO question.

Don Stewart