problems with pthread_cond_broadcast

[Sebastien Decugis]

> > 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"
> > 
> 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".
> 
> 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.
> 
> 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.
> 
> 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). 

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...


-- 
Sébastien DECUGIS
Bull S.A.
Tel: 04 76 29 74 93