Re: Q about pthread condition variable usage - mixing interlocks

[David Holland <dholland-tech%netbsd.org@localhost>]

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
dholland%netbsd.org@localhost