Re: Audio threads scheduling
Re: Audio threads scheduling
- Subject: Re: Audio threads scheduling
- From: Shaun Wexler <email@hidden>
- Date: Mon, 5 Apr 2004 07:52:22 -0700
On Apr 5, 2004, at 7:31 AM, Shaun Wexler wrote:
The constraint value should be less than or equal to the total cycle
period minus the output latency and safety offset. The computation
value should be less than or equal to the actual unpreempted
computation time required by the ioProc. It's the minimum computation
that is tricky. The constraint minus the computation is the maximum
length of time in the thread can be preempted and safely blocked
without missing its deadline. How the scheduler determines when to
afford cycles to the thread is of course up to the scheduler. As long
as the thread receives no less than the computation's worth of cycles
per period, the scheduler is free to split that up in the constraint
period however it chooses. By careful selection of these parameters,
you can request or enforce nearly any timing behavior you require.
It's a well designed system.
That should read: "The computation value should be NO LESS than the
actual unpreempted (ie total) computation time required by the ioProc."
The way for the HAL to get away with a relaxed scheduling algorithm is
to set the constraint equal to the cycle period, which is in fact too
high and should actually be no greater than constraint = cycle period -
output safety offset time.
How about a dependency queue, where you break your processing into
stages, which would each be enqueued for processing as soon as its
dependencies were satisfied. Thread(s) would drain the shared queue
until the whole series of stages in each of the graphs were processed,
regardless of which thread was processing which stage. The only time
a thread would block would be waiting on a dependency to be processed
where there were less than X stages remaining to process, in which
case the thread that was currently processing the critical stage would
then signal at completion. That would almost break the inter-thread
dependency (or completely break it if needed), and allow any number of
graphs to be processed concurrently by any number of threads. At
least that's how I'd approach it. ;)
And that should have read: "The only time a thread would block would
be waiting on a dependency to be processed where there were MORE than X
stages remaining to process, in which case the thread that was
currently processing the critical stage would then signal on that
stage's completion."
--
Shaun Wexler
MacFOH
http://www.macfoh.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.