[concurrency-interest] Context-switching VS Continuation

Dawid Kurzyniec dawidk at mathcs.emory.edu
Thu Jun 9 10:10:08 EDT 2005

Jean Morissette wrote:

>Hi all,
>	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 mailing list