Re: relative thread priorities
Re: relative thread priorities
- Subject: Re: relative thread priorities
- From: "Jeremy Todd" <email@hidden>
- Date: Tue, 18 Sep 2007 20:02:01 -0400
This sounds reasonable. Is there any way to prevent a thread's priority from
degrading? If not, are there any guidelines for how often I need to yield
the CPU to avoid degradation?
Threads A and B have perhaps 5 minutes of work to do each, so they are
certainly going to be preempted before yielding explicitly. In both cases,
it's difficult to keep track of "time". They're just a bunch of for loops
and function calls and calculations whose complexity varies depending on
input data, etc.
Can I err on the side of yielding the CPU too often without any negative
performance impacts? Should I try to check some clock very often, and yield
every N microseconds? I just can't see a clean way to do this without
relying on the OS and thread scheduler to do it for me.
Regards,
Jeremy
> 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.
>
> --
>
> Jeff Moore
> Core Audio
> Apple
_______________________________________________
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