Re: Can pthread_cond_signal() block?
Re: Can pthread_cond_signal() block?
- Subject: Re: Can pthread_cond_signal() block?
- From: Philippe Wicker <email@hidden>
- Date: Sat, 2 Nov 2002 22:08:20 +0100
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.
Regards,
Philippe Wicker
email@hidden
_______________________________________________
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.