>>>>> On Wed, 23 Jul 2008 15:49:34 -0700,
      Jason Thorpe <thorpej@shagadelic.org> said:

quoted text
> SA is a win only when you have MANY threads blocking on user-space  
> synchronization primitives, and in that case, the benefit is  
> diminished greatly when you have threads being time-sliced against  
> each other because the timer firing involves the kernel (our  
> libpthread time-sliced by default).

There are some sort of multi-thread programs that thread
synchronization happens far more often than time-slicing
or I/O blocking.
e.g. Some simulations which give thread context to each object.
The effect of time-slicing you said doesn't matter on such programs.

The attached graph is a result such sort of benchmark
which was measured on 2003 October when SA was merged
(X-axis is number of threads, log-scale.  Y-axis is time
[microsecond], log-scale).
This benchmark does something like UNIX pipe, but uses threads
instead of processes for the pipeline.
As you see, userland implementations except pth (i.e. mit threads
and ptl) and SA are always faster than 1:1 implementations,
even if there is only two threads.


Also, (theoretically) SA is ALWAYS faster or at least equal
than 1:1 thread implementations on single processor systems
for ANY multi-threading programs.
And most low-end embeded systems, which is one of fields that
NetBSD has advantage, only has single processor.


So, I don't think it's right thing to abandon SA at this point.
-- 
soda