There were two threads giving each one a time quanta and measured how much time context switch takes (of course included some warm up)
sched_yeild - 377us Boost.Contex - 214us Dummy - 10us
All tests done on a single CPU using taskset 0x1 ./test params
So finally I can see that Boost.Context does not behave **much** better then OS context switch?
Hmm - did you see the performance measuring test coming with the lib (libs/context/performace)? It counts the CPU cycles taken by a switch. The tool was used to compare ucontext_t (which does some system calls for preserving the signal mask) and fcontext_t (which doesn't perserve the signal mask and is which is implemented in assembler).
I modified it and I measured following (AMD Athlon(tm) 64 X2 Dual Core Processor 4400+):
cmd: performace -s -i 100
sched_yield(): 2108 cycles ucontext_t: 1795 cycles fcontext_t: 156 cycles
Actually it is quite consistent with what you had show, the Boost.Context is better (but not significantly) then real OS (kernel) context switch.
Maybe you can send me your test code?
I'll send it later (no access to that PC now)
Usefulness of N:M model (or even 1:M model) -------------------------------------------
Indeed the OS develoeprs moved from N:M to 1:1 (so as Solaris did) and the N:M paradigm may not usefull for OS but may for user-land apps.
But I use it for instance in boost.task to allow a task create and wait on sub-tasks using boost.context. This allows work-stealing by other worker-threads.
It would be very useful to see real usability cases. Because otherwise it is hard to estimate usefulness of this library
In general it is usable in all cases where the code may want to jump to another execution path but wants to come back and have all local data preserved in order to continue its work.
I understand, it may be useful for "yeild" like iterators and so but it is not clear how does it work and what is the advantage in comparison to ordinary event driven approach. Regards Artyom