Re: More thread scheduling observations
Re: More thread scheduling observations
- Subject: Re: More thread scheduling observations
- From: Kurt Revis <email@hidden>
- Date: Sun, 5 May 2002 10:42:02 -0700
On Sunday, May 5, 2002, at 09:39 AM, Ian Ollmann wrote:
Now, here is the problem. If we have everyone scheduling themselves at
PRI
64 with timesharing off, we will end up with an arms race and nobody
will
get the dependability they want.
I was starting to wonder about that. Thank you for the very complete
explanation--some of it I had heard before, but I hadn't seen a good
explanation of what exactly timeshare/not timeshare meant. (Previously
everyone seemed to be concentrating on time-constraint threads...)
Anyway, as you suggested, I tried turning down the importance, and
things still work fine. Importance=4 seems to be my lower bound; any
lower than that and window-dragging causes dropouts.
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.
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.
(The multiple layers and versions of these thread calls makes tracing
this stuff through the kernel kind of difficult for the untutored... not
to mention the fact that there's a thread_policy_set() AND a
thread_set_policy()! Eeek.)
More privileges come with greater reponsibility.
Oh, I completely understand and agree with that, after freezing my
machine a few too many times when playing with time-constraint threads!
I have no desire at all to go back to the Bad Old Mac days when any old
program would randomly hose everything...
--
Kurt Revis
email@hidden
_______________________________________________
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.