Re: Audio threads scheduling
Re: Audio threads scheduling
- Subject: Re: Audio threads scheduling
- From: Stéphane Letz <email@hidden>
- Date: Mon, 5 Apr 2004 11:12:27 +0200
Le 4 avr. 04, ` 23:30, Shaun Wexler a icrit :
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...
Which is basically what my additionnal threads are going to do....
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.
Where did you see this 79 priority? I always though the Windows server
had a 63 priority...
This means that a real time thread was indeed preempted by a lower
priority thread during its constraint (ie not during the computation
period).
You mean that your real time thread had still something to do? Quite
strange... In this case how can the scheduler guaranty your real time
thread *constraint* value?
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.
Why the HAL? The contraints and computation are going to be used by the
scheduler?
My understanding is that the HAL set the contraints and computation
parameters during the IO thread creation but not after.
What happens if you block during the computation period?
It *will* block during the computation period... I mean if the thread
is preempted by the scheduler at the end of its computation slice,
we're in the normal case.
In my audio graph execution case, the thread is going to bock during
its computation period because it has nothing to do more (the graph is
is a sequence subpart where there is no other parallel node to compute)
*but* the suspended thread may have to be resumed in the *same* audio
cycle because at some point later in the cycle, a parallel part in the
grah is reached.
The idea here is to try to alwys feed both processors when possible.
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.
Isn't the pthread_cond_signal/wait API using the kernel semaphore API?
What are the advantage of using the kernel semaphore API?
And again I don't see how this change the base problem : one of the 2
additional thread may have to be suspended and resumed in the cyle
before returning to the IO thread.
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...
;)
Yes. This is another idea. This will use only 2 threads instead of 3.
But here also the threads may have to wait because of data dependancies
issue. Another issue is that the thread contraint/computation
parameters will be fixed by the HAL, whereas the thread
contraint/computation may be choosen differently in the "additional
threads" solution.
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.