[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: revivesa status 2008/07/09
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
> > 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
Main Index |
Thread Index |