Re: More thread scheduling observations
Re: More thread scheduling observations
- Subject: Re: More thread scheduling observations
- From: Herbie Robinson <email@hidden>
- Date: Mon, 6 May 2002 03:37:10 -0400
Is the value of 'importance' in the structure for
THREAD_PRECEDENCE_POLICY the number you are talking about when you
say "PRI=64"? Or is the importance added to the task's base
priority to get the real priority? The fact that I can go so low
with the importance seems to indicate the latter.
"Importance" is relative to the base priority, as you suspect. And
yes, the large number of ways to set thread priorities is definitely
confusing. :-)
Anyway, to continue my other question of "how does iTunes do it?":
a little gdb work shows that it is calling down to thread_policy()
for a few threads. I am not really clear on how the old
thread_policy() stuff corresponds to the new
thread_policy_set/get(), but it looks like it's using a round-robin
policy with values of 37 and 38 for a couple of its threads. This
is sort of tantalizing, but I haven't actually verified that this
isn't just a standard thing that Carbon sets up for its deferred
and asynchronous calls.
Carbon does this automatically for Deferred Task and Async File I/O
threads. Both of these threads are fixed-priority round-robin
threads.
Everybody, please take Ian's warnings to heart. Making youself
equal to the Window Server's event handling is a Bad Thing(tm). If
you coming to WWDC, definitely check out the CoreAudio talks as I
imagine this topic will be covered. There is also a specific
session on multithreading.
stephen
Please bear in mind that Professional Audio is a "one strike you are
out" business. When I'm recording a concert, I can't run up to the
stage and ask the band to stop and play the song over again. That
means that missing recording a take because the OS decided to pretty
up the screen is NOT an appropriate tradeoff. That also means that I
can't just experiment a bit and pronounce that maybe it will work, I
have to have some way to prove with a fairly large amount of
certainty that nothing is going to suddenly wake up and ruin my
recording.
It would be nice to always have enough CPU to keep the screen updates
snappy, but when CPU ticks get rare, a Pro Audio application MUST
steal from the screen response to keep the most important stuff (the
audio) running.
To me, this says that things like feeder threads should be running
real-time (obviously pre-emptable) at a fairly long time interval (1
sec or so). The appropriate algorithm would queue all the disk I/O
for the interval and sleep. That said, I believe that a feeder
thread that is doing disk I/O would not be taking up huge amounts of
CPU time; so, it probably corresponds to the definition of something
that is OK as a real-time thread, right?
--
-*****************************************
**
http://www.curbside-recording.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.