Re: Can pthread_cond_signal() block?
Re: Can pthread_cond_signal() block?
- Subject: Re: Can pthread_cond_signal() block?
- From: EJ Campbell <email@hidden>
- Date: Sat, 02 Nov 2002 00:50:12 -0800
On Friday, November 1, 2002, at 06:55 PM, EJ Campbell wrote:
On Friday, November 1, 2002, at 05:23 PM, David Leimbach wrote:
I have a tendency to use semaphores as a "signaling primitive" and a
work queue using a "producer/consumer" style design. Once the queue
is empty the consumer is asleep on the semaphore's value is zero the
producer can wake it up by posting to the semaphore. I don't know if
the post [which is like your cond-signal in some ways] blocks or not
but its an option.
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.
Still no luck. Much like pthread_cond_signal(), the call to sem_post()
performs beautifully 99.9999% of the time, but occasionally takes an
extremely long time to complete (if 312 microseconds can be called
that) . For example, during the last run of my program, here's how long
the call to sem_post() took immediately before and after the anomalous
call (these times are in nanoseconds).
382
366
308
400
371
310
312339
413
423
333
Any ideas as to what else I should try?
Thanks,
EJ
_______________________________________________
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.