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: Sun, 3 Nov 2002 15:14:10 +0100
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.
From my own experience with "midi" thread being lost in infinite loop,
I would say that either the Mach kernel or the CoreAudio engine have a
mechanism to give some CPU from time to time to - for instance - the UI
thread. I was able to kill a looping "midi" thread by opening a
terminal window, typing "top" and then "kill" (of course I had to wait
some time for the terminal window to open).
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.