On Sat, 2006-06-10 at 00:37 +0200, Stefan Westerfeld wrote:
> 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.
Well, sem_post is supposed to be async-signal safe (meaning it can't be
preempted, meaning it's realtime safe). If the Linux people have broken
that, they have done an evil stupid thing. POSIX semaphores are great,
especially since you can (or at least should, apparently) signal things
from signal callbacks and realtime threads with them (they work great
for event-driven systems).
Are you sure? Link?
-DR-
Received on Sat Jun 10 16:15:01 2006
This archive was generated by hypermail 2.1.8 : Sat Jun 10 2006 - 16:15:02 EEST