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: Sun, 03 Nov 2002 05:17:21 -0800
On Saturday, November 2, 2002, at 10:27 PM, EJ Campbell wrote:
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.
Actually, my method was bogus. I was not calling
AbsoluteToNanoseconds() on the value returned by UpTime(). However, the
numbers, when compared to one another, are still correct; it's the
scale that is wrong. The important fact is that the anomalous call to
sem_post() took approximately a thousand times longer than normal.
On my machine, the value returned by AbsoluteToNanoseconds() is 40
times greater than UPTime()'s raw output. Adjusting the above list
yields these results, which are now actually in nanoseconds:
1528
1464
1232
1600
1484
1240
1249356
1652
1692
1332
Sorry about that.
-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.