Re: revivesa status 2008/07/09

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sat, Jul 12, 2008 at 07:05:43PM +0100, Mindaugas Rasiukevicius wrote:
 > Well, question in previous email still valid:
 > 
 > - Do you have a real-world scenario, that is application, when you need many
 >   threads on UP system which do not do any blocking (no I/O, no syscalls, no
 >   or limited synchronisation)?

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.

So I'm not convinced that these workloads don't exist.

 >>> Well, it is "well-understood" in theory. SA was a kind of nice idea from
 >>> theoretical perspective, 

I'm not convinced of that. I've argued in the past that it's not the
right model, and I'll do so again if provoked - basically the problem
is that what you actually need is M:N:P (M user threads on N kernel
threads on P processors) and the lack of explicit cognizance of P
messes up the design.

The mess in the design is exactly why the implementations run into
trouble.

 > > Let's not confuse N:M to SA. Which other system do you know that used SA?
 > 
 > OK, not sure what was Solaris' M:N implementation, but FreeBSD's KSE were
 > similar to SA by Anderson. From what I understand looking at the code (see
 > kern_kse.c), the same upcalls and new-thread-on-block way was used.
 > 
 > Recently they removed KSE from -current.

Digital Unix's thread library was a scheduler activations
implementation. I don't think it was ever withdrawn as such.

-- 
David A. Holland
dholland%netbsd.org@localhost