> 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? -- meem
