Re: Can pthread_cond_signal() block?
Re: Can pthread_cond_signal() block?
- Subject: Re: Can pthread_cond_signal() block?
- From: William Stewart <email@hidden>
- Date: Mon, 4 Nov 2002 12:08:09 -0800
Something to know about with the real-time (time constraints) threads...
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.
With Jaguar the scheduler will not pre-empt TC threads (though given
the existence of the preemtible flag this may *not* always be the
case...
Basically with the TC threads one of the fields that you provide as
part of the TC is the computation bounds:
thread_time_constraint_policy_data_t thePolicy;
thePolicy.period = mPeriod;
thePolicy.computation = xxx
This value (which is in nanoseconds) determines the period of time
which a TC thread will run before the scheduler will consider another
thread of equal priority to execute. If the TC thread is still running
after that quantum of time, the scheduler checks to see if there is
another TC thread, if so, the current thread goes to the back of the TC
thread queue, the next TC thread executes until either its quanta of
time elaspses, or it sleeps... and so on until there are no runnable TC
threads...
Because of this, we set the computation bounds of TC threads in the HAL
differently based on buffer size of that I/O Proc (as that represents
some period of time).
Imagine two I/O Procs (in different processes):
(1) Has a buffer size of 512/44.1K -> so approx 11msec
(2) Has a buffer size of 128/44.1K -> approx 3 msec
If (1) does a lot of work (say it takes 4 msecs to do its thing), (2)
still has to run every 3 msecs or it will miss.
So, we set the computation quanta for (1) to be small - 100 nanos. -
For (2) we set it higher (300 nanos) - In the testing we did with this
we were able to run both processes where they both do substantial work,
but not sufficient in combination to overload the machine or overload
their individual time constraints.
There is a desire to have the scheduler be able to make these decisions
itself based on the information that is provided in the TC structure -
so it is important that you fill these fields out correctly. For
instance, I would expect that ANY thread that does not have hard and
fast I/O deadlines to meet, would set the premptible flag to true, so
that those threads who do have those deadlines can pre-empt the softer
TC threads.
I would expect these changes to be made at some point. If you are using
TC threads (and we'd still like to strongly advise that you DON'T
unless you've examined all other possibilities and found this is the
only alternative - those examinations should also be done on Jaguar,
not 10.1, as there were some very important changes in Jaguar in
relation to the priorities and work-loads of various system services -
most notably the window server).
We'd also prefer it if, having reached this conclusion, you emailed us
(either privately or on the list) to explain your problem to see if we
can either characterise this bad behaviour as a bug - which we then fix
- of help you to understand what, if anything, you're doing wrong.
Why are we so paranoid about this:) - If everyone uses TC threads, then
it becomes an arms race between I/O deadlines and application
processing - and I/O deadlines should win, but can't if TC threads are
being used in a somewhat arbitrary manner. With jaguar, we're finding
that the need to use TC threads for processing types of activities has
been basically removed - and we get the timing behaviours we need
through the use of Round Robin, Priority == 63 threads.
>
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.
Don't know - this would be better asked on the darwin list I suspect.
>
>
> 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.
We "often" see these loops when we're mucking with stuff - it generally
takes 8 seconds for the thread to be smashed, but after that has
elapsed the system will revert to normal behaviour in our experience
Bill
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
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.