On Thu, Apr 08, 2021 at 10:47:09AM -0700, Jason Thorpe wrote: > Is there ANY situation where, for a given pthread condition > variable, that using a different mutex as the interlock in two > different calls to pthread_cond_wait() would EVER be legitimate > usage? I cannot come up with any scenario in which this would be > appropriate, but who knows what some crazy applications might do.
It is not a reasonable thing to do and there's no scenario I know of where it makes sense. That mutex had better protect the state that expresses the condition the CV is associated with, or things don't work. > POSIX for whatever dumb reason allows pthread_cond_signal() / > pthread_cond_broadcast() without holding the interlock, but at > least there?s explicit language about this in the spec (and > thankfully the language contains a mild finger-wag about it). For implementations with Mesa semantics (though not Hoare semantics) this is a reasonable thing to do, e.g. to avoid holding a heavily contended mutex for any longer than absolutely necessary. Since wakeups are only advisory, it doesn't matter if you unlock first and thereby allow the state to change before the wakeup goes through. Allowing it excludes some implementation strategies though, because it means you can't rely in on the mutex to protect the CV's internal state. -- David A. Holland dholl...@netbsd.org
