https://bugs.kde.org/show_bug.cgi?id=360557
--- Comment #2 from Ari Sundholm <a...@tuxera.com> --- (In reply to Philippe Waroquiers from comment #1) > (In reply to Ari Sundholm from comment #0) > > > The reason why I am so puzzled by this is that both on line 36 and line 61 > > the mutex for the element is held. > > Are you sure the lock is always held on line 36 (that does b.var2++;) ? Yes. > pthread_cond_wait will release the lock. > So, on the next loop, b.B_lock is not held anymore. This is not the case, as, per standard semantics for condition variables, pthread_cond_wait re-acquires the mutex before returning to the caller. The description of the semantics of the function on the relevant manpage: ====================== pthread_cond_wait atomically unlocks the mutex (as per pthread_unlock_mutex) and waits for the condition variable cond to be signaled. The thread execution is suspended and does not consume any CPU time until the condition variable is signaled. The mutex must be locked by the calling thread on entrance to pthread_cond_wait. Before returning to the calling thread, pthread_cond_wait re-acquires mutex (as per pthread_lock_mutex). Unlocking the mutex and suspending on the condition variable is done atomically. Thus, if all threads always acquire the mutex before signaling the condition, this guarantees that the condition cannot be signaled (and thus ignored) between the time a thread locks the mutex and the time it waits on the condition variable. ====================== -- You are receiving this mail because: You are watching all bug changes.
