problems with pthread_cond_broadcast

Sebastien Decugis sebastien.decugis at ext.bull.net
Thu Apr 15 07:27:10 UTC 2004


Hi,

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.

Best regards,

Sebastien.


Le jeu 15/04/2004 à 07:50, Thorsten Kukuk a écrit :
> Hi,
> 
> I have a problem with pthread_cond_wait/pthread_cond_broadcast
> waiting sometimes forever on a fast SMP machine. Attached is a
> simple test case.
> 
> If I use the order
>   pthread_mutex_unlock (&lock);
>   pthread_cond_broadcast (&pcond);
> 
> with NPTL, the program will hang after a short time running with
> current glibc + NPTL + kernel 2.6.x on all architectures I tested.
> 
> If I revert the order to 
>   pthread_cond_broadcast (&pcond);
>   pthread_mutex_unlock (&lock);
> 
> it works fine.
> 
> Is this a problem of the test case (since pthread_cond_broadcast and
> pthread_cond_wait will access pcond at the same time in different
> threads) or is this a glibc/NPTL/kernel problem?
> 
>  Thanks for any hint,
> 
>     Thorsten
-- 
Sébastien DECUGIS
Bull S.A.





More information about the Phil-list mailing list