Re: Audio threads scheduling
Re: Audio threads scheduling
- Subject: Re: Audio threads scheduling
- From: Stéphane LETZ <email@hidden>
- Date: Thu, 1 Apr 2004 03:51:25 +0200
>
--__--__--
>
>
Message: 4
>
From: Jeff Moore <email@hidden>
>
Subject: Re: Audio threads scheduling
>
Date: Wed, 31 Mar 2004 12:14:03 -0800
>
To: CoreAudio API <email@hidden>
>
>
One last thing, I should caution that the parameters the HAL uses for
>
scheduling it's IO threads can and will change in the future as the
>
system evolves and we learn more about it. In other words, I wouldn't
>
write code that depends on this stuff working this way.
>
>
On Mar 31, 2004, at 12:10 PM, Jeff Moore wrote:
>
>
> The computation value indicates the initial period for which the
>
> thread will not be pre-emptible. I believe that this is implemented in
>
> scheduler by when it sets the decrementer interrupt to next go off.
>
>
>
> The HAL chooses the value for this parameter so that shorter IO cycles
>
> get more time to not be pre-emptible and longer cycles become
>
> pre-emptible sooner. This, in effect, prioritizes the shorter cycle
>
> over the longer cycle.
>
>
>
> This prevents a priority inversion that can occur when there are
>
> cycles with both large and small durations in which the IOProcs are
>
> using reasonable CPU loads. For instance if both Process A and Process
>
> B are using 25% CPU load in their respective IOProcs, but A's cycle is
>
> 4000 frames long and B's cycle is 100 frames long. If A's cycle didn't
>
> become pre-emptible quickly enough, it would easily cause B to miss
>
> many of it's cycles, even though both processes are using reasonable
>
> CPU loads.
>
>
>
> It also encourages IOProcs to execute faster so the thread can go back
>
> to sleep as this is less likely to get pre-empted.
>
>
>
> On Mar 31, 2004, at 1:10 AM, Stiphane Letz wrote:
>
>
That was not what I was understanding reading the documentation for
THREAD_TIME_CONSTRAINT_POLICY :
Parameters:
period: This is the nominal amount of time between separate
processing arrivals, specified in absolute time units. A
value of 0 indicates that there is no inherent periodicity in
the computation.
computation: This is the nominal amount of computation
time needed during a separate processing arrival, specified
in absolute time units.
constraint: This is the maximum amount of real time that
may elapse from the start of a separate processing arrival
to the end of computation for logically correct functioning,
specified in absolute time units. Must be (>= computation).
Note that latency = (constraint - computation).
preemptible: This indicates that the computation may be
interrupted, subject to the constraint specified above.
I was thinking that as soon as the thread is marked *preemptible*, then
the scheduler is free to divide up the "computation" duration into
several slices in order to meet the deadline of all threads, in
particular when the threads don't have the same period.
There is nothing said in the doc about the relationships between the
"computation" parameter and the thread preemptibility.... Or the
documentation is not correct?
Thanks
Stephane Letz
_______________________________________________
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.