[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pthread_cond_signal() ambiguity
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. :)
Main Index |
Thread Index |