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.
Correct.
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 thread. 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, Wolfgang