Re: problems with pthread_cond_broadcast

Hi,

I think this problem is the same as:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=3D115349
and
http://bugme.osdl.org/show_bug.cgi?id=3D2364

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 =E0 07:50, Thorsten Kukuk a =E9crit :
> Hi,
>=20
> 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.
>=20
> If I use the order
>   pthread_mutex_unlock (&lock);
>   pthread_cond_broadcast (&pcond);
>=20
> with NPTL, the program will hang after a short time running with
> current glibc + NPTL + kernel 2.6.x on all architectures I tested.
>=20
> If I revert the order to=20
>   pthread_cond_broadcast (&pcond);
>   pthread_mutex_unlock (&lock);
>=20
> it works fine.
>=20
> 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?
>=20
>  Thanks for any hint,
>=20
>     Thorsten
--=20
S=E9bastien DECUGIS
Bull S.A.


--=20
Phil-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/phil-list