On 4 Jan 2003 at 0:46, Henrik Nordstrom wrote:
> What I expect is that on SMP systems most systems will try to have the
> CPUs running when possible.
thats sure. The only thing to keep in mind is that running thread can't easily
trigger other cpu. There must be suitable conditions for that, other cpu must
be necessarily suspended in either halt or some mutex spin, and running cpu
must parse through all the internals to find that out. Its slow.
I bet that highly likely is that restart notice is just put onto some queue to let
running thread to proceed at full speed. Only when running thread blocks,
there is suitable time to parse the runqueue. Its pretty much similar to what
we in squid do - we add to the request queue, and sometime later worker
threads pick the job up. Main thread doesn't do much more.
> On UP systems I do not really expect much. I did expect that a yield
Well, this depends heavily on OS. Solaris for eg has no difference whether
UP system or SMP. OS codepaths are exactly the same, just number of
CPUs is 1. On Linux I'm not sure, but given that threads there are actually
processes, I don't think there is much difference in code path either.
> > Cond_signal is documented to unblock "at least one thread".
>
> I still maintain that two cond_signal from the same thread SHOULD
> unblock "at least two threads" however.
yes, thats true. quite likely on most OSes.
> One idea.. as we do not really care for predictable scheduling of
> cond_signal, perhaps cond_signal should be moved outside the mutex lock
> to give schedulers more freedom (and avoid the window of implementations
> scheduling the threads while the mutex is still held by the signalling
Whatever the docs say, cond var should not be touched outside mutex.
There are some rare cases when race conditions could cause a thread deadlock.
Not the one signalling, but the one waiting on condvar.
And this would happen, on one OS or other. I've had these on Solaris 2.5 or 2.6,
even UP back then. Maybe these days such things are avoided, and iirc this
can be recovered by timedwait, so in a sense, not very important, but this could
cause other weird interactions that we'd better avoid. Win is very questionable
and very small.
Received on Sat Jan 04 2003 - 07:22:04 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:19:05 MST