Re: Can pthread_cond_signal() block?
Re: Can pthread_cond_signal() block?
- Subject: Re: Can pthread_cond_signal() block?
- From: kelly jacklin <email@hidden>
- Date: Sun, 03 Nov 2002 06:24:22 -0800
EJ Campbell <email@hidden> wrote:
>
> I have a tendency to use semaphores as a "signaling primitive" and a
>
> work queue using a "producer/consumer" style design.
>
> [snip]
>
>
This sounds promising. Which semaphore API are you using? The one
>
defined by POSIX (the sem_* variety) , the one from multiprocessing
>
services (MP*Semaphore), or some other API? The POSIX API looks most
>
promising since it seems to have been created with realtime usage in
>
mine. In fact, unlike the multiprocessing API, it explicitly mentions
>
how to avoid priority inversion.
Neither. He is referring to the one in mach. See
/usr/include/mach/semaphore.h. The implementation of the pthread API for
pthread_cond_signal calls semaphre_signal_thread, but only after taking the
meta-lock on the condition variable (a spin-lock). So it is possible for
contention to occur (on MP system, not on UP) with this meta-lock (although
it is true that the window is very narrow, i.e. just the metalock which is
only held briefly).
Assuming that the semaphore_signal_thread call does not block, this would be
the way to go. Furthermore, the semaphore APIs provide "sticky"
synchronization (like all semaphores), so this should provide the
opportunity to remove the timeout spinning entirely.
Please (again) avoid the MPSemaphore calls. These are layered atop
pthreads, with a global-per-process termination lock and two pthread
construct usages for both the post and wait operations. Use as low as
possible. Believe it or not, the MP API is pretty high-level in its
implementation...
kelly jacklin
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.