looking in pthread's source code I can see that as an epilogue both pthread_cond_timedwait and pthread_cond_wait will try to relock the mutex by means of __pthread_mutex_cond_lock.
Does this mean that any of them both could eventually block forever if the mutex is never again available after waiting for the conditional variable signal? This does not seem to be the expected behavior for a timed call.
thanks,
Rodrigo
Whose pthread source code? There are lots of pthread implementations out there.
You should acquire the mutex before calling phtread_cond_wait
pthread_mutex_lock(&m)
/* sleep wait */
while (!condition)
pthread_cond_wait(&c, &m);
do_your_thing();
pthread_mutex_unlock(&m);
linux, glibc 2.5
Right, before waiting on a conditional variable you must hold the mutex. But once within the 'wait' method itself the mutex will be released while waiting on the conditional variable queue (waiting for the conditional variable being signaled or broadcast.)
Once the signal arrives then 'wait' must guaranty that the mutex is acquired again before returning to the 'wait' caller. That's the basic mechanics for a conditional variable. Reacquiring the mutex, as much as I understand, is always something that one would expect implemented with the API at hand, in this case pthread.
My point is that in this pthread implementation relocking the mutex goes without a timed call, that is, the whole method could block forever if something went wrong with the thread that should have released the mutex. Therefore, it is possible that pthread_cond_timedwait would block for ever, which is exactly what one is trying to avoid by using a timed version of 'wait'.
Yes, it is very possible for that to happen.
I am not sure what your understanding of how pthread_cond_timedwait works is. I would point out that once the wait time expires and is turned off, the thread is moved off the sleep queue. Likewise once a sleeping thread is signaled, even by error, it is taken off the sleep queue and the wait timer is turned off. This does not mean that it re-acquires the mutex, etc. If it takes another week before reacquiring the mutex, too bad. If it never gets the mutex back because the other thread has not released it, too bad.
If you have the Lewis & Berg book on Pthreads, this issue is discussed on pages 94 -99. Dave Butenhof also discusses this issue in his book on Pthreads. See section 3.3.2 et al.
BTW, a thought just struck me, are you trying to port a Win32 application which uses eventing to GNU/Linux?
i see that your understanding is then the same as mine.
realizing this detail in pthread (at least for the implementation i'm using) was a bit of a surprise. i try to use timed calls (pass timeout) just to be sure that the application will give a last sign of failure before giving up, instead of blocking there silent for ever.
fortunately no!