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 22:27:17 -0800
On Saturday, November 2, 2002, at 01:08 PM, Philippe Wicker wrote:
On Saturday, November 2, 2002, at 09:50 AM, EJ Campbell wrote:
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
I suppose that your measure consists of sampling the host time (with
AudioGetCurrentHostTime for instance) before and after the call. Even
if you proceed like that, don't forget that this sequence of action is
not atomic. You may be preempted by a higher priority thread between
the first time sampling and the second. You may also be interrupted by
a hardware interrupt (if enabled, an hardware interrupt is always
having priority over any thread). Among the possible interrupts, there
is a particular one, the system tick (each 10 ms), which may activate
the scheduler and therefore take some time to execute. So I would say
that your numbers are not so anomalous. I would even say that If the
scheduler never takes more than 300 microseconds, they are good
numbers.
My method boils down to calling UpTime before and after the
synchronization call. I'm sorry if I wasn't more clear, but I'm making
these calls from a realtime thread. Since the call is from a realtime
thread, preemption from another thread should not be a problem. You're
right, a hardware interrupt could occur while the call is taking place,
but that shouldn't last 250,000 nanoseconds. I'm not sure what happens
when the system tick occurs during a realtime thread, but again, I
don't think that would cause the anomalies I'm seeing.
The only thing I think I need to worry about is blocking because that
can cause a priority inversion and realtime threads should not block.
It seems clear that all of the synchronization primitives that I've
tried (MPNotifyQueue, pthread_cond_signal, and sem_post) can block if
they're called at precisely the wrong time, and this is what my
profiling data has shown.
In addition to bracketing the call to the synchronization primitive
with UpTime, I also measure the elapsed time between calls to my sound
completion handler. Again, most of the time my completion handler is
called at regular intervals. However, if the call to the
synchronization primitive takes a long time (like 300,000 nanoseconds
case above), my next completion handler is delayed as well, which means
audio frames are lost.
Finally, if I remove the synchronization call, my completion handler is
always called in a regular fashion, so it's clear that synchronization
call is the problem.
-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.