[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
As far as Pthreads standards go, calling pthread_cond_signal() and having the
associated mutex unlocked is legal.
Below is what the standard says:
"The pthread_cond_signal() or pthread_cond_broadcast() functions may be
called by a thread whether or not it currently owns the mutex that threads
calling pthread_cond_wait() or pthread_cond_timedwait() have associated with
the condition variable during their waits; however, if predictable scheduling
behaviour is required, then that mutex is locked by the thread calling
pthread_cond_signal() or pthread_cond_broadcast()."
However reading NetBSD's man page, it suggests that having the mutex unlocked
might produce undefined results:
"The same mutex must be held while calling pthread_cond_broadcast() and
pthread_cond_signal(). Neither function enforces this requirement, but if the
mutex is not held the resulting behaviour is undefined."
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.
Main Index |
Thread Index |