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 14:25:46 -0800
On Sunday, November 3, 2002, at 11:24 AM, Herbie Robinson wrote:
At 3:14 PM +0100 11/3/02, Philippe Wicker wrote:
On Sunday, November 3, 2002, at 07:27 AM, EJ Campbell wrote:
Since the call is from a realtime thread, preemption from another
thread should not be a problem.
I never had a deep look at the Mach kernel code, so the following
remarks are based on my experience in realtime programming on OS like
Linux (kludged realtime - kernel calls are not reentrant - which
implements FIFO and ROUND ROBIN fixed priority scheduling algorithm)
and LynxOS (true real time OS from scratch, FIFO and ROUND ROBIN
with priority inheritance to solve the priority inversion). I will
have a deeper look at thread scheduling under Mach kernel to see how
it apply to MacOS X.
A realtime thread may be preempted while running. It depends on the
scheduling policy. It the thread is using a realtime FIFO scheduling
policy, it may be preempted - at any time - by a higher priority
thread but not by an equal or lower. If the thread is using a
realtime ROUND ROBIN scheduling policy, then it may be preempted at
any time by a higher priority thread (as soon as the latter becomes
eligible, on an IO completion for instance) , and by an equal
priority thread (this is the difference with the FIFO mode), the
switch between the two threads being decided by the scheduler in the
system tick processing.
Assume there is two threads running in realtime mode with equals
priorities (the real case being the thread in context of which the
MIDIProc is called, and the thread in context of which the IOProc is
called, or two IO threads in 2 different processes). If the
scheduling policy for both threads is FIFO, and if the running thread
is - for instance - the "audio" thread, then the "midi" thread will
not acquire the CPU until the "audio" one yields the CPU. Because the
IOProc is likely to be the place where the DSP job is done, it may
take some time for this to happen.
If both threads are running ROUND ROBIN, then they will be preempted
by turn by the scheduler at the tick system time or possibly when
calling for an IO operation.
EJ Never mentioned it, but presumably he is using the real time thread
scheduling parameters (THREAD_TIME_CONSTRAINT_POLICY) specified in
<mach/thread_act.h>. We can probably also assume that he set the
"preemptible" flag to false.
My realtime threads are assigned whatever priority CoreAudio assigns to
its IO threads. My worker threads are high priority "regular" threads.
Thanks everyone for your help.
-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.