relative thread priorities
relative thread priorities
- Subject: relative thread priorities
- From: "Jeremy Todd" <email@hidden>
- Date: Sat, 15 Sep 2007 23:06:50 -0400
Hi,
I'm working on a Carbon-based audio application, and I've recently tried to
understand the OS X thread scheduler. Here is what I'm trying to set up:
- There's a CoreAudio thread which is created as a time-constrained thread
as I understand it. I'd prefer not to touch that thread.
- There's the application's main thread. The priority is apparently 47 for
now, I have no idea whether this is always true.
- Background thread 1 needs to run with lower priority than the GUI thread
(I don't want it to let the GUI become unresponsive, or to block the audio
thread, but otherwise it should run as much as possible).
- Background thread 2 needs to run with lower priority than background
thread 1.
As documented in other posts and in some sample code, I can call:
thread_policy_set( .. THREAD_EXTENDED_POLICY .. ) to turn off time-sharing
then
thread_policy_set( .. THREAD_PRECENDENCE_POLICY .. ) to set each thread's
"importance". I'm assuming the main thread has "importance" of zero. I set
background thread 1 to have "importance" of -1, and background thread 2 to
have "importance" of -2.
After doing this, I can see that background thread 1 has priority 46 and
thread 2 has priority 45. The problem is that when background thread 1 is
busy, background thread 2 is still able to run fairly often, to the point
where it significantly degrades the performance of background thread 1.
If I change this so that background thread 2 has "importance" of -40, then
things look much better. Background thread 2 is no longer able to
significantly degrade the performance of background thread 1.
I found a post from Jim Magee back in 2001:
http://lists.apple.com/archives/darwin-development/2001/Oct/msg00351.html
stating that thread "importance" is strictly ordinal.
That would be great if it's true, but from what I'm seeing above, the
importance is used to set thread priorities, and thread priority values seem
to have some meaning. I've seen lots of posts about the number 63 being some
upper non-realtime limit, and the number 96 being a realtime priority. Are
these numeric values of priority documented or guaranteed anywhere?
I was hoping to avoid worrying about actual thread priority numbers. It
seems that the guidelines for being a well-behaved app in a multithreaded
system are to state your needs and leave everything else to the kernel. In
this case, my needs are that background thread 2 cannot significantly
degrade the performance of background thread 1. Can anyone point me toward a
simple way to express this using the pthread or Mach APIs?
If there isn't a simple answer I think I'm hoping for some insight into why
my GUI thread has priority 47, and whether this can change over time (I
haven't touched its scheduling policy), or whether it can change from
computer to computer, and how I can decide what to make background thread
2's priority to achieve my needs.
Note that I'm not worried about my application with respect to other
processes running on the system. I'm just trying to get relative thread
priorities working reliably inside my application.
I hope this all makes sense - after several hours of reading older posts and
header files, I wasn't able to come up with a solid answer, and this seems
to me like a fairly basic need for a multi-threaded application so I hope
I'm missing something obvious.
Regards,
Jeremy Todd
iZotope, Inc.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden