Thanks for your all your answers. I think we got an insightful
discussion going. I also think we got almost everything cleared up.
Let's hope that some mainstream magazine publishes numbers that show
just how Linux is being outperformed at the pthreads level and that
that changes the attitudes of the linux kernel team. (Which is what
happened with some Apache benchmarks, from what I can tell.)
Well, you'll still need to have a convincing implementation...
I'm still feeling a bit misunderstood on one point, though:
>
> > However, I think the case we're looking at here may be slightly different.
> > In our case, one thread (A) is running on one CPU, and another thread (B)
> > is running on another. Thread A holds a lock, thread B wants to acquire it.
> > Once thread A unlocks the lock, thread B could just go ahead and run
> > on the other CPU. In this case, *neither* CPU would have to context
> > switch. It would simply be a system call executed on each CPU.
>
> Assuming B doesn't do busy-waiting, if it finds the mutex locked by A,
> it has no choice but to suspend and presumably the kernel will then
> switch context to another runnable process. Later, A unlocks the
> mutex, and seeing that B is waiting on it, will restart B.
>
You say that the kernel will then "switch context to another runnable
process". My argument was considering the case that there is
*no other runnable* process in the system (i.e., 2 processors, 2 runnable
threads)-- and that the second CPU will therefore go idle until it is
resumed by the first CPU via IPI. My question was whether *this* case is
still as expensive as a context switch.
Secondly, Jeff had commented that the Netscape NPSR people did
implement some kind of two-level scheduling. I had always thought
that this would require kernel support. For instance, on Solaris,
the kernel uses SIGLWP to inform the user-level scheduler when it has
run out of LWPs and needs to create new ones. If you don't have
SIGLWP, you can't use native I/O (i.e., read(2) etc. on blocking
filedescriptors)---how does netscape do it?
- Godmar
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
