secret of light-weight user thread

[Simon Marlow]

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