On Wed, Jul 23, 2008 at 03:52:09PM -0700, Jason Thorpe wrote:
quoted text
>> You can do a lot of synchronization, as long as it's synchronization
>> with other threads in the same process. Nothing in principle says you
>> need to go into the kernel for every synchronization op; and in fact
>> you shouldn't, unless you're synchronizing with another process or
>> you've run out of runnable threads.
>
> And, on UP systems, you don't.

Shouldn't on MP systems either :-)

(not that I know if we do or not, I haven't looked inside libpthread
in a couple years.)

quoted text
> I just don't believe that there are very many apps that actually behave 
> like this.

Right now there aren't, overall, very many apps that are threaded such
that the threading buys much in the way of performance. There also
aren't, overall, very many apps that make 10,000 user threads, because
it doesn't work, at least not without using Erlang or some other
similar environment with its own threading code.

Both of these things are likely to change over the next five to ten
years. (Unless the industry decides instead to just stagnate, which is
a distinct possibility.)

I don't remember if I said this in my previous post or not, but I do
think there is something to be gained by multiplexing threads;
however, scheduler activations are the wrong model for doing so.

Also, all of this is irrelevant. revivesa should go in as part of
COMPAT_40, because otherwise we break compat and there's no reason not
to. Meanwhile, replacing ad's shiny new 1:1 threads with anything else
anytime soon would be stupid.

-- 
David A. Holland
dholland@netbsd.org