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