Joerg Sonnenberger <joerg@britannica.bec.de> 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
have.