[Haskell-cafe] Re: Bound threads

Wolfgang Thaller wolfgang.thaller at gmx.net
Sat Feb 26 01:21:30 EST 2005

> I'm trying to understand the semantics and implementation of bound 
> threads
> basing on the conc-ffi paper and others.
> Since the main thread is bound, and unbound threads are never executed
> on an OS thread which has some Haskell thread bound, this would imply
> that when the main thread spawns a Haskell thread and they synchronize
> a lot with each other using MVars, the synchronization needs OS-thread
> synchronization - the threads will not execute on a the same OS thread.


> If I understand this correctly, doesn't it impose a significant
> overhead compared to synchronizing two unbound threads? If not,
> what am I missing?

Yes, it does impose more overhead than synchronizing two unbound 
threads. Depending on how high your demands are and on how good your 
operating system is at OS-thread synchronization, it might or might not 
be significant.

We need the main thread to be bound because the main thread is special 
for some libraries (Apple's Carbon and Cocoa libraries, and, to a 
lesser extent, Microsoft's Win32). Some calls to these libraries 
absolutely have to be executed in the main thread and not in any other 
So treating the "call" to main the same way as other calls into Haskell 
code (using a bound Haskell thread) was the nicest solution to this; 
the performance disadvantage you pointed out can be easily worked 
around by just doing _all_ the work in unbound threads (and having the 
main thread just wait for the unbound threads to terminate).

Hope that answers your question,


More information about the Haskell-Cafe mailing list