[concurrency-interest] Context-switching VS Continuation
dawidk at mathcs.emory.edu
Thu Jun 9 10:10:08 EDT 2005
Jean Morissette wrote:
> I would be happy to have your comments on this...
>First, we are building a SEDA-based framework, http://jcyclone.sf.net, which
>is designed to support massive degrees of concurrency. Our framework is a
>little bit like a graph of executors (Stages) linked by queues.
>Actually, we are working on an innovative (or weird) continuation-based
>scheduler that eliminate context-switch. The idea is to instrument
>user-provided classes (event handlers) in such a way that the thread context
>(call stack, etc) is saved in a continuation object when a thread encounters
>a wait(), and can be restored later. When notify() is called on the monitor,
>a waiting continuation is put in the ready queue of the scheduler.
Somehow I doubt that it could outperform normal context switching. After
all, the "continuation switching" is a lot like context switching
implemented at the user level. Why would it be faster than switching
performed close to the hardware, where the amount of state is smaller
and also you can take advantage of kernel-mode, fine-tuned assembly
language, etc? Also, one of performance hits related to context
switching is caused by cache flushing. You will not avoid it anyway.
Linux prior to 2.6 had poor thread switching performance, AFAIK mostly
because there was no dedicated abstraction of a thread at the low level
(threads were essentially processes). MS Windows and Solaris were
actually much better in that respect, since they supported threads
natively. But Linux kernel 2.6 has changed the game - all the threading
stuff has been reimplemented, and it is much faster now. I can't give
exact numbers, but I would suggest you first run some benchmarks to
measure the overheads that you are trying to beat.
More information about the Concurrency-interest