Subject: Re: Please Revert newlock2
To: None <email@example.com>
From: Bucky Katz <firstname.lastname@example.org>
Date: 02/20/2007 20:25:33
Joerg Sonnenberger <email@example.com> 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
> Yes, but how expensive is that trap? I mean if the application is
> using corporative multithreading it can as well just use coroutine
It could be completely rewritten using an event model and no threads
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.