[Haskell-cafe] You are in a twisty maze of concurrency libraries, all different ...

[Duncan Coutts]

On Fri, 2009-12-04 at 22:51 +1100, Patrick Caldon wrote:
> I'm looking for the "right" concurrency library/semantics for what 
> should be a reasonably simple problem.
> 
> I have a little simulator:
> 
> runWorldSim :: MTGen -> SimState -> IO SimState
> 
> it takes about a second to run on a PC. It's functional except it whacks 
> the rng, which needs IO.

Wait! This is not going to work!

You cannot use the MTGen from the mersenne-random in a concurrent IO
program because the C code uses a single global mutable RNG state. Your
"independent" simulations would not be independent and you would not get
reproducible results. Indeed you could get incorrect results or
segfaults because the C code does not expect to be called from multiple
threads simultaneously (there is no locking).

Personally I would attack this by eliminating the IO. There's no
justification for a random number generator being in IO. And look at the
problems it causes!

There are other MT implementations that do not use C code which assumes
it's ok to use one single global mutable RNG state for an entire
process. There are pure-Haskell MT impls that use mutable variables in
ST but give an overall pure lazy list of random numbers. If you don't
need MT specifically then there are other fast RNGs too.

Duncan