Re: More thread scheduling observations
Re: More thread scheduling observations
- Subject: Re: More thread scheduling observations
- From: Stephen Davis <email@hidden>
- Date: Sun, 5 May 2002 12:19:55 -0700
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
_______________________________________________
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.