Re: pthread_cond_signal() ambiguity

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

Sad Clouds <cryintothebluesky%googlemail.com@localhost> wrote:
> So if another thread is calling pthread_cond_signal() without having a
> mutex locked, there must be some hidden mutual exclusion going on in the
> pthreads library on that condition variable, in order to allow this to
> happen in a safe way. Does anyone know low level details of how NetBSD
> implements these functions?

Yes, there is an internal lock for pthread_cond_t, however it is a subject
to few issues with real-time threads when interlock is not held, see the
following comment:

http://nxr.netbsd.org/xref/src/lib/libpthread/pthread_cond.c?r=1.54#32

Apart from additional issues, it also illustrates that avoiding interlock
for pthread_cond_signal() wont buy anything.  It would move contention to
internal lock, but would not avoid it.  Also, to change the predicate,
interlock would need to be held anyway.

-- 
Mindaugas