Re: Audio threads scheduling
Re: Audio threads scheduling
- Subject: Re: Audio threads scheduling
- From: Shaun Wexler <email@hidden>
- Date: Sun, 4 Apr 2004 14:30:05 -0700
On Apr 4, 2004, at 1:01 PM, Stiphane LETZ wrote:
And suspension is done using a "pthread_cond_timedwait" (or
something similar) which period equal the buffer size duration. Is
this correct?
Not exactly; the wait time is a maximum timeout, and the thread is
blocked waiting on a condition variable semaphore to become
available. In effect, the thread awakes when signaled and/or times
out.
Who is going the signal the thread?
Availability of the condition variable signals the blocking semaphore
of CAGuard's parent mutex. I have not examined the exact usage of the
timespec in the implementation, but I assume the HAL simply uses it as
a wakeup timer, to coincide with the beginning of the next IO cycle's
computation period, but if any other thread notifies the CAGuard, it
will be awoken prior to timeout, such as when a new buffer list
becomesavailable in the kernel; the HAL may choose to call the ioProc's
immediately, rather than have them wait until their timeouts...
I think the question here is to see if they are differences for the
scheduler in the following cases:
- a real-time thread is prempted because it reached the end of it's
"computation" slice (the "computation" parameter defined in the time
constraints setting)
- a real-time thread finished it's job, control go back to the HAL
that finally suspend the thread with something like
"pthread_cond_timedwait" and return control to the scheduler
- a real-time thread suspend itself with "pthread_cond_wait", but it
will be resumed in the same audio cycle.
As an example, my app runs multiple threads for drawing: a rendering
thread, and one or more threads per-screen for synchronization
purposes. The sync threads use extended policy with priority 63, and
the rendering thread is normal timeshare 31. While profiling a certain
DSP computation, its period would increase 150% when a flush thread had
more work to do, in which case it was blocked on mach_msg_trap, while
the window server of priority 79 would blit the window backing store.
This means that a real time thread was indeed preempted by a lower
priority thread during its constraint (ie not during the computation
period).
This allows a low-priority thread the opportunity to lock the mutex,
thus preventing realtime thread(s) from running, hence the potential
for priority inversion.
I agree in the general case. But here I'm thinking of cases where the
lock is never going to be taken by a low-priority thread
Again, the problem is that you may end up "fooling" the HAL into
believing that your ioProc requires more unpreemptible cycles that it
really needs. What happens if you block during the computation period?
Are you ALWAYS going to block at the same point? The best thing to do
is to have the ioProc "controlling" your audio graph threads via
semaphore_wait_signal, in which case the signal semaphore will awaken
the appropriate thread(s), which both complete their work, and return
to the ioProc thread, which can then return. That way the HAL can
assume the total ioProc period was correct, and it will continue to
base its computation/constraint on that amount of time (the sum of your
dependent threads' periods). In fact, there is no reason this can't
work, since your dependent threads would be blocked awaiting the
ioProc's signal. You would need to wrap their completion
semaphore_signal calls with an atomic flag, though.
But designing systems that can take the more of bi-processor machines
(and probably soon bi + HT) is challenging...
You could also register additional ioProc's with the same device, and
selectively push/pull certain buffers for each of your threads, without
ever blocking the ioProc's or requiring additional threads... ;)
--
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.