Re: problems with pthread_cond_broadcast
Sebastien Decugis <[email protected]> Thu, 15 Apr 2004 10:04:13 +0200
| Newsgroups | gmane.comp.lib.phil |
|---|---|
| Message-ID | <[email protected]> |
> > 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" > >=20 > Yes, it is legal to call pthread_cond_broadcast() after=20 > pthread_mutex_unlock(). But POSIX above says "have > associated with the condition variable during their waits". >=20 > This means for me, that they called already pthread_cond_wait() and > not that they are allowed to call pthread_cond_wait() at the same > time as pthread_cond_broadcast() with the same condition variable. >=20 > I cannot find anything in POSIX which says, that it is allowed that > pthread_cond_wait() and pthread_cond_broadcast() access the same > variable at the same time, for me it always sounds like POSIX expects > that other threads are already waiting. >=20 > So are both functions allowed to access the same variable at the > same time or not? I would expect that they are not allowed to do > so and cannot find something different in POSIX. Actually, it seems to me that there is an internal lock in the pthread_cond_t structure, so I think the pthread_cond_wait() and pthread_cond_broadcast() cannot run concurrently (but there might be a race condition I did not see).=20 Concerning the standard, I think that only two cases are possible (assuming that the pthread_cond_XXX functions are atomic against other pthread_cond_XXX functions.): - Either pthread_cond_broadcast() is called while no other thread is waiting on the condition variable. In this case does nothing. - Or it is called while one or more threads are waiting. Then a mutex is (dynamically) associated to the cond var, and the threads shall be awaken. Please correct me if there is no such thing as this atomicity in the NPTL... --=20 S=E9bastien DECUGIS Bull S.A. Tel: 04 76 29 74 93 --=20 Phil-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/phil-list