Re: Can pthread_cond_signal() block?
Re: Can pthread_cond_signal() block?
- Subject: Re: Can pthread_cond_signal() block?
- From: Herbie Robinson <email@hidden>
- Date: Sun, 3 Nov 2002 14:24:46 -0500
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.
As long as we are on this subject, I am curious about one thing.
Does the preemptible flag control masking of hardware interrupts, or
just task scheduling? Please don't answer this with conjecture, I
would like to hear from somebody who is sure about the answer.
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).
There is a field in the time constraint policy structure that
specified how long each iteration of the thread will run. If one
exceeds that by some gross amount (a couple of seconds, I think), the
system reverts the thread to normal priority. You should notice
single CPU systems hang for a bit when there is an infinite loop in a
real time thread. You won't be able to operate the UI until after
the hang. I haven't managed to make infinite loops for a while; so,
it's possible they have tightened up the timing on Jaguar to make the
hang less noticeable. With a dual CPU system, you would need
infinite loops on both CPUs to notice a hang.
--
-*****************************************
**
http://www.curbside-recording.com/ **
******************************************
_______________________________________________
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.