>
> > IIRC the main reason for this was to avoid priority inversion -- if you
> > drop the lock and get preempted by a higher-priority thread before you
> > can cv_signal(), the cv_signal won't happen for a while and so a
> > higher-priority thread in cv_wait() might not get to run for a while.
>
> OTOH, if you cv_signal() while you're holding the lock, isn't it possible
> the signaled thread will wake up, be unable to grab the lock (since the
> signalling is still holding it), go back to sleep (or perhaps spin) and
> have to be poked again when the signalling thread actually does drop the
> lock?
Whether this is good or bad, this is the official requirement. A quote from
the condvar(9F):
cv_signal() signals the condition and wakes one blocked
thread. All blocked threads can be unblocked by calling
cv_broadcast(). You must acquire the mutex passed into
cv_wait() before calling cv_signal() or cv_broadcast().
I bet, though, that some pieces of Solaris code ignore this requirement - for
better or for worse.
- Alex Kolbasov
