Re: Quasi-realtime threads
Re: Quasi-realtime threads
- Subject: Re: Quasi-realtime threads
- From: Jeff Moore <email@hidden>
- Date: Mon, 6 Jul 2009 15:48:54 -0700
Making your thread be a FIFO thread more or less causes it to not
degrade in priority when it becomes CPU bound. If this is fixing your
problem, it likely means that the ultimate cause of your problem was
that your pull-thread was getting it's priority whacked because it is
CPU-bound. What I imagine was happening is that your pull-thread is
running long enough so that it's priority degrades far enough to get
pre-empted by something else. The fact that doing more work on this
thread via AU rendering exacerbates the problem is a pretty good clue
that this is what is going on.
The net effect of all this to an outside observer would be to increase
the amount of jitter in the scheduling latency for the thread when it
is being signaled to wake up. Thus, by making your pull-thread's
priority not degrade, you are preventing the scheduler from degrading
the priority and pre-empting it.
This is a reasonable fix, but you might want to analyze your pull-
thread's work flow a bit more. The usual reason for priority
degradation in a normal user-thread is that the thread is doing too
much work without yielding the processor. By elevating this work to a
thread whose priority isn't going to degrade, you have the potential
to introduce some starvation in other threads as they won't run as
often. Generally, this won't be much of a problem as the number of
cores increases, but the uni-processor case may suffer dramatically if
you are talking about an iPhone application, for example.
One thing to try to mitigate this problem without resorting to a FIFO
thread is to attempt to break down the work of the pull-thread into
smaller chunks to allow the thread to yield a bit more often.
As to why this fails on 10.4, my only guess would be that
pthread_setschedparam() wasn't fully implemented in that OS, but I
don't know for certain.
On Jun 30, 2009, at 6:27 PM, Ethan Funk wrote:
UPDATE:
I have things working well on OS X 10.5 using the following approach
to raise my audio pull pthread to a realtime-like thread:
struct sched_param p;
p.sched_priority = sched_get_priority_max(SCHED_FIFO);
if(pthread_setschedparam(pthread_self(), SCHED_FIFO, &p))
ServerLoger->MakeEntry("Failed to set thread priority.");
On OS X 10.4 however, the sent audio is very broken up. The
pthread_setschedparam call is not returning an error however, so I
don't know what is different in the pthread library between the OS
versions. It appears as if 10.4 is just ignoring the thread
schedule change. Any ideas?
--
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