On 06/09/2011 09:47, Kazu Yamamoto (山本和彦) wrote:
Recently I exchanged information about user threads with Ruby community in Japan.
The user threads of Ruby 1.8 are heavy weight and Ruby 1.9 switched to kernel threads. The reason why user threads of Ruby 1.8 are heavy weight is *portability*. Since Ruby community does not want to prepare assembler to change stack pointers for each supported CPU architecture, Ruby 1.8 copies the stack of user threads on context switch.
Because I need to explain why the user threads of GHC are light weight, I gave a look at GHC's source code and found the loadThreadState function in compiler/codeGen/StgCmmForeign.hs. In this function, the stack pointer is changed in the Cmm level.
So, my interpretation is as follows: Since GHC has Cmm backend, it is easy to provide assembler to change stack pointers for each supported CPU architecture. That's why GHC can provide light weight user threads.
Is my understanding correct?
There are a couple of reasons why GHC's threads are cheaper than OS threads, it's not really to do with the Cmm backend: - We have an accurate GC, which means that the Haskell stack can be movable, whereas the C stack isn't. So we can start with small stacks and enlarge them as necessary. - We only preempt threads at safe points. This means that the context we have to save at a context switch is platform-independent and typically much smaller than the entire CPU context. Safe points are currently on allocation, which is frequent enough in GHC for this to be indistinguishable (most of the time) from true preemption. User-space threads are often dismissed because of the problems with implementing concurrent foreign calls. We have a nice solution for this problem in GHC that I think is probably under-appreciated in the wider language community: http://community.haskell.org/~simonmar/papers/conc-ffi.pdf Cheers, Simon