Joerg Sonnenberger <joerg@britannica.bec.de> writes:

> 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.

It could be completely rewritten using an event model and no threads
at all.

Of course, it's a big application and it's already working.

> 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.

It depend on the nature of the application. It has been my experience
that for applications that do significant synchronization the
performance gains are huge.

> 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.

Yes. That's even more complex than SA...

> 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.

You can do a fine job of thread local storage without a kernel trap.

But yes, you can always find a feature that if you exploit causes you
problems.  This is why Sun got m:n threads wrong in Solaris: trying to
solve all problems, they solved none.