tech-userlevel archive

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

Re: pthread_cond_signal() ambiguity

Sad Clouds <> 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:

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.


Home | Main Index | Thread Index | Old Index