Message: 1
Date: Mon, 17 Sep 2007 15:06:55 -0700
From: Jeff Moore <email@hidden>
Subject: Re: relative thread priorities
To: CoreAudio API <email@hidden>
Message-ID: <email@hidden>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
You've said that you are creating two threads, A and B. The
threads are being set with a precedence of -1 and -2
respectively vs. the main thread. The problem you've stated
is that it appears that thread B is running too often and is
starving thread A even though A has a higher priority than B.
You've also said that depressing the priority of B by a lot
gets the behavior you are looking for.
So given that, I put to you that you do not have a problem
with priorities. The problem you have is that you are not
accounting for the kind of work being done on the two
threads. My guess is that what is happening here is that you
have a calculation running on A that is going compute bound.
This in turn is causing A's priority to degrade to the point
where it is lower than the priority for B. The fact that
depressing B's priority manually "fixes" the problem is
usually a tell that this is the case. The way to fix this is
to break up the long running calculation in A a little bit by
manually yielding the CPU from time to time.
Another aspect of the problem may be the fact that A and B
are running concurrently on a multi-CPU system. If there are
two processors open and both threads are marked runnable,
then they will definitely run concurrently. If you don't want
that to happen, you'll need to take steps to prevent it, such
as using a mutex or other of the various synchronization
primitives on the system.
On Sep 15, 2007, at 8:06 PM, Jeremy Todd wrote:
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.h
tml 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.