On Tue, Feb 20, 2007 at 07:37:47PM -0800, Bucky Katz wrote:
> Anytime the library level scheduler can bypass a trip to the kernel
> because it can do a switch the overhead of the kernel trap is
> saved.

Yes, but how expensive is that trap? I mean if the application is using
corporative multithreading it can as well just use coroutine
implementations.

> The more threads you use, especially the more that synchronize,
> the more likely you are to find one thread about to sleep on some kind
> of even while you've got another one runable.  The finer grained your
> use of thread synchronization is, the worse the problem becomes -- and
> that's actually true independent of the architecture, so long as a
> kernel trap is more expensive than a procedure call.

As it was said already, the complexity of SA is huge. I think that for
most applications the performance gains are much lower than one would
expect. Large parts of the pthread library can be implemented to avoid
the need for context switches with proper atomic instruction support,
esp. if UP is all that is needed.

The trap overhead is also not avoidable on many platforms as soon as
e.g. Thread Locale Storage enters the game. That will happen soon
enough, so the gains of SA are diminished by that anyway.

Joerg