Subject: Re: Please Revert newlock2
To: None <email@example.com>
From: Bucky Katz <firstname.lastname@example.org>
Date: 02/21/2007 09:57:59
Joerg Sonnenberger <email@example.com> writes:
>> 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.
> That's why I am asking for the type of beast you are dealing with.
One written by programmers who believe in threads and who do a lot of
synchronization. I'm really not at liberty to describe it in more
detail, although I could generate a synthetic benchmark if there was
justification for it.
In general you can characterize it as 10s of threads per lwp, and the
optimal number of lwps being one per processor + one more. threads
tend to be worker threads that dispatch on events occuring and use
synchronization to trigger internal dispatch. There is a high
probability at any time that when one thread blocks another will be
ready to run. A high percentage of the blocks are synchronization,
while the rest are blocking system calls.
> No, it is not, because you don't have to deal with all problms for
> it to work.
You're right. I overspoke.
> One of the major differences is that it is that the complexity is
> kept outside the kernel, which is a very good thing as it reduces
> the impact of any problem a lot.
Keeping complexity outside of the kernel is a VeryGoodThing(tm)!
> That said, I'm sorting out the building blocks necessary to do
> almost the same as SA without the kernel side complexity. What I
> have in mind would help a lot for non-threaded architectures as
> well, but I need more time to think about it.
Cool. I've thought about this over the years, but I've never been
able to get around the need for a certain amount of cooperation from
the kernel. I'd be happy to be a sounding board for any ideas you