[Haskell-cafe] Re: Bound threads
wolfgang.thaller at gmx.net
Sat Feb 26 01:21:30 EST 2005
> I'm trying to understand the semantics and implementation of bound
> 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
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