Bound Threads

Alastair Reid alastair at
Thu Mar 6 09:46:14 EST 2003

> Does anyone plan to add support for multiple OS threads to Hugs or NHC?

I think it will depend a bit on the complexity so let me sketch how I
think it can be implemented.

First let me outline my current understanding of what 'bound' means.
Consider the following scenario:

  Haskell program is running in OS thread 't1'
  Haskell program calls C function 'foo'.
  'foo' forks a new OS thread 't2'.
  In parallel: 't1' calls Haskell function 'f1' and
               't2' calls Haskell function 'f2'
  'f1' calls C function 'g1'
  'f2' calls C function 'g2'

My understanding is that 'bound' requires that 'g1' be executed by
thread 't1' and that 'g2' be executed by thread 't2'.  It would be
nice if 'f1' and 'f2' could run simultaneously but the ffi is not
going to impose that on us.  If 'f1' were to block on an MVar, 'f2'
could start running and vice-versa.  While 'g1' is running, 'f2' can
run and while 'g2' is running, 'f1' can run.

Based on this understanding, I believe that single-threaded runtimes
could easily implement 'bound' by doing nothing more than using a lock
to ensure that at most one OS thread executes Haskell code at once.
Thus, a global lock would have to be acquired when a bound function is
called or when a thread starts running and the lock would be released
when a thread stops running (completes, calls out to C or blocks).

This sounds pretty simple (a few tricky corner cases to get right but
no major upheaval in the runtime systems) and the locking requirements
are quite modest (so, hopefully, portable) so I think an
implementation is pretty likely to happen.  Timescale will depend on
when people find time or money to do it.

Alastair Reid                 alastair at  
Reid Consulting (UK) Limited

More information about the FFI mailing list