tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pthread_cond_signal() ambiguity

Luke Mewburn <> 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. :)


Home | Main Index | Thread Index | Old Index