7 Jun
2006
7 Jun
'06
7:42 p.m.
On Wed, 2006-06-07 at 20:32 +0200, Fons Adriaensen wrote:
On Wed, Jun 07, 2006 at 08:49:38AM -0400, Paul Davis
wrote:
But, from the original post it seems that pthread_cond_signal is not
realtime safe as it locks a mutex:
__pthread_cond_signal (cond)
pthread_cond_t *cond;
{
/* Make sure we are alone. */
lll_mutex_lock (cond->__data.__lock);
/* Are there any waiters to be woken? */
if (cond->__data.__total_seq > cond->__data.__wakeup_seq)
{
/* Yes. Mark one of them as woken. */
++cond->__data.__wakeup_seq;
++cond->__data.__futex;
/* Wake one. */
lll_futex_wake (&cond->__data.__futex, 1);
}
/* We are done. */
lll_mutex_unlock (cond->__data.__lock);
return 0;
}
How can glibc guarantee that we are not put to sleep if there is
contention?
Lee
nice to hear that they are faster. on the other
hand, once again POSIX
screws us all over by not integrating everything into a single blocking
wait call. i've said it before, i'll say it again - this is one of the
few things that the win32 API gets right - you can block in one call on
almost *anything*. AFAICT, you cannot select/poll on a msg queue.
You can build such a thing on top of condition variables - that
is what they exists for - to let a thread wait one any condition
you may want, no matter how complicated.