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:
> > 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:
> > >
> > > > 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.
> > >
> >
> > But, from the original post it seems that pthread_cond_signal is not
> > realtime safe as it locks a mutex:
>
> The big question is: who cares? :) sem_post() is. A mutex/cond pair is
> just a big ugly slow non-RT-safe semaphore anyway.
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/~stefanReceived on Sat Jun 10 04:15:01 2006
This archive was generated by hypermail 2.1.8 : Sat Jun 10 2006 - 04:15:01 EEST