secret of light-weight user thread
marlowsd at gmail.com
Tue Sep 6 12:40:33 CEST 2011
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
> 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
> 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
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
More information about the Glasgow-haskell-users