Andres Kroonmaa wrote:
> It seems to me you have abit too bright expectations from threads.
Not so sure about that.
What I expect is that on SMP systems most systems will try to have the
CPUs running when possible.
On UP systems I do not really expect much. I did expect that a yield
would kick the scheduler, but this expectation is no more (unless RT is
used, in which case I still expect RT properties to be in place).
I ahve never really expected mutexes to trigger scheduling unless they
must. This is why the yield was put in there in the first place to try
to be nice to the I/O threads and give them the little time they need
once per comm loop. Unfortunately yielding does not help but it probably
is not important either.
> Cond_signal is documented to unblock "at least one thread".
Have been reading a little more, and yes, it is how it is documented.
I still maintain that two cond_signal from the same thread SHOULD
unblock "at least two threads" however.
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
thread). When making the changes earlier today I was a bit unsure about
the relation between mutex and cond variables, but it is now 100% clear
to me that there is no such requirement of a mutex relation between the
signalling and signalled thread, only among the waiting/signalled
threads.
Regards
Henrik
Received on Fri Jan 03 2003 - 17:17:24 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:19:05 MST