Re: [PATCH] threaded pack-objects: Use condition variables for thread communication.

[Dmitry Potapov <dpotapov@gmail.com>]

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