On Sun, Dec 16, 2007 at 08:00:16PM +0100, Peter Baumann wrote: > On Sun, Dec 16, 2007 at 07:41:37PM +0100, Johannes Sixt wrote: > > On Sunday 16 December 2007 13:05, Peter Baumann wrote: > > > On Sun, Dec 16, 2007 at 12:18:53AM +0100, Johannes Sixt wrote: > > > > + > > > > + progress_lock(); > > > > + me->working = 0; > > > > + progress_unlock(); > > > > + pthread_cond_signal(&progress_cond); > > > > > > Shouldn't the pthread_cond_signal be inside the lock? > > > e.g. swap progress_unlock() with pthread_cond_signal(&progress_cond) > > > > No, that's not necessary. Both ways are correct, but if it's outside the lock > > there is less contention on the mutex (because the waiting thread must > > acquire the mutex lock before it can return from pthread_cond_wait). > > > > At least I was told otherwise and [1] backs my knowledge up. Are you > really sure? > > -Peter > > http://docs.sun.com/app/docs/doc/806-5257/6je9h032r?a=view#sync-53686 The POSIX standard clearly says that usage of pthread_cond_signal ouside of the mutex protection is allowed: === 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(). === http://www.opengroup.org/onlinepubs/007908775/xsh/pthread_cond_signal.html And the argumentation provided by Sun's manual: > Otherwise, the condition variable could be signaled between the test > of the associated condition and blocking in pthread_cond_wait(), which > can cause an infinite wait. sounds strange to me. Indeed the condition variable could be signaled between the test and blocking, but the condition itself is false, so the thread should be blocked anyway. The only effect of signalling outside of the mutex protection is that the thread blocked on the condition variable can be waken up while the associated condition is still false, but it is not a problem. As to what is more optimal, it is less clear. Because on one side, signaling under the lock increases contention, but, on the other hand, it avoids spurious wakeup. So, I suppose it could be implementation specific. Dmitry - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
