https://bugs.kde.org/show_bug.cgi?id=374414
Ivo Raisr <iv...@ivosh.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |iv...@ivosh.net
--- Comment #1 from Ivo Raisr <iv...@ivosh.net> ---
POSIX [1] also states that the lock does not need to be held:
"The pthread_cond_broadcast() or pthread_cond_signal() 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
behavior is required, then that mutex shall be locked by the thread calling
pthread_cond_broadcast() or pthread_cond_signal()."
The above applies to mutexes that have priorities associated
with them, that is, either ceiling mutexes (PTHREAD_PRIO_PROTECT) or
priority-inheritance mutexes (PTHREAD_PRIO_INHERIT). Normal mutexes
do not contain any priority scheduling; therefore there is usually a (tiny)
performance benefit to call mutex_unlock() before calling cond_signal().
[1]
http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_cond_signal.html
--
You are receiving this mail because:
You are watching all bug changes.
