Re: pthread_cond_signal() ambiguity

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Luke Mewburn <lukem%NetBSD.org@localhost> wrote:
>   | Now my question is: does anyone think that NetBSD's implementation
>   | of pthread_cond_signal() is broken? I think quite a few people
>   | intentionally unlock the mutex before calling pthread_cond_signal(),
>   | so that the thread that wakes up can lock this mutex asap. and start
>   | running, instead of blocking.
> 
> AFAICT, the NetBSD manual page and/or the implementation are wrong
> in this respect.
> 
> Based on my investigation on this topic recently, it is valid to call
> pthread_cond_signal() (and _broadcast()) without the mutex held,
> according to the POSIX standard and other implementations I've also
> used (Linux 2.6, Darwin).
> You'll get an unpredictable wakeup of the sleeping thread, and/or
> possibly a spurious wakeup, so you need to retest the condition
> after being awoken, but that should be it.

NetBSD's implementation is not wrong in this respect, although manual
page might be improved.  Applications which use signal/broadcast without
interlock held are likely broken, as Jean-Yves already explained.  That
is the reason why in our kernel cv_signal()/cv_broadcast() usage without
interlock held is considered a bug.

There might be some cases, when such use is safe and POSIX probably permits
it due to such possibility (*).  NetBSD follows the standard, one _can_ signal
a thread without interlock held, but it is strongly not recommendation, as
such uses are rarely correct.  Actually, if I remember correctly POSIX also
states such recommendation.


* It also permits recursive locking, just because it is possible.  While we
probably all agree about fundamental issues with it. :)

-- 
Mindaugas