problems with pthread_cond_broadcast

[Jakub Jelinek]

On Thu, Apr 15, 2004 at 09:30:38AM +0200, Thorsten Kukuk wrote:
> > I think this problem is the same as:
> > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115349
> > and
> > http://bugme.osdl.org/show_bug.cgi?id=2364
> > 
> > Moreover, POSIX says:
> > "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"
> > 
> > So there is a bug in either NPTL or kernel futexes (FUTEX_REQUEUE ?), as
> > your use of pthread_cond_broadcast() after pthread_mutex_unlock() is
> > legal.
> 
> Yes, it is legal to call pthread_cond_broadcast() after 
> pthread_mutex_unlock(). But POSIX above says "have
> associated with the condition variable during their waits".

The testcase is correct from what I can see.

pthread_cond_{,timed}wait must be called with the associated mutex
held, while pthread_cond_{signal,broadcast} may but don't have to.
The standard says that you should hold the associated mutex in
pthread_cond_{signal,broadcast} if you want predictable scheduling
behaviour, but that doesn't change anything on conformance when the
mutex is not held.
Of course you are allowed to access the same condvar with p_c_wait and
pc_c_broadcast at the same time.

Ulrich spent quite some time on this FUTEX_REQUEUE issue, though I don't
think the bug has been discovered.
So for the time being we ship RHEL3 with FUTEX_REQUEUE disabled.

	Jakub