9 Jun
2006
9 Jun
'06
8:17 p.m.
Hi!
On Wed, Jun 07, 2006 at 09:04:45PM -0400, Dave Robillard wrote:
On Wed, 2006-06-07 at 17:42 -0400, Lee Revell wrote:
As far as I understand from the linux-2.6.16.16 and glibc-2.3.6 code,
a semaphore has similar problems, as sem_post() is implemented in terms
of futexes on newer linuxes, and futexes have a list of waiters, which
is protected by a lock within the kernel.
But the unlikelyness of a priority inversion problem that has been
pointed out by others probably applies to any of the synchronization
primitives that came up in this thread, be it conditions, pipes or
semaphores.
Cu... Stefan
--
Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan
On Wed, 2006-06-07 at 20:32 +0200, Fons
Adriaensen wrote:
The big question is: who cares? :) sem_post() is. A mutex/cond pair is
just a big ugly slow non-RT-safe semaphore anyway. 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: 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.