Re: Time Problem with NSThread
Re: Time Problem with NSThread
- Subject: Re: Time Problem with NSThread
- From: Jeff Moore <email@hidden>
- Date: Mon, 2 Jan 2006 11:58:13 -0800
100ms is definitely not out of the realm of possibility when it comes
to getting a thread held off. There are numerous reasons why this
might happen, even on a relatively idle system.
At any rate, I don't know what the true priority the thread will get
with that NSThread call (you can find out with the command 'ps -auxM'
which lists all the threads in all processes including their
priorty), but if we assume that it is getting assigned the maximum
user priority, which is 63 and is higher than the UI threads, but
lower than all the kernel threads, and definitely lower then the
HAL's IO thread.
One way to hold things off is to make system calls that create
activity in kernel threads, like disk IO or whatever. You may even
have some piece of hardware generating absurd amounts of interrupts
or somehthing. You should be able to see this sort of thing if you do
a system trace with Shark and look at the thread activity. It can
show you the events that led the scheduler to swap your thread out as
well as what thread got to run instead.
Another way to spike the thread is to have it go CPU bound long
enough to have it's priority degrade to the point where it gets no
time any longer. This is easier to do than you think if you are doing
lots of math in loops (like for DSP!) on the work thread. Again, a
system trace with Shark may shed some light on things.
Finally, the easiest way to do it is with your own code. You should
look to see if there are any locks or other bottlenecks in your code
that the work thread might be blocking on. Since you said that this
works well on MP systems, this is probably the least likely scenario
since you'd probably get other kinds of problems there too. Shark can
help with this too.
So I guess at this point, you'll probably want to use Shark or some
other tool (e.g. the CALatencyLog code in our SDK) to analyze the
scheduler activity and try to see what circumstances are leading to
your thread not running when you think it should.
On Dec 30, 2005, at 1:58 PM, Wayne Anderson wrote:
I tried setting the priority to max, [ NSThread setThreadPriority:
1.0 ]. This does not seem to help.
Again, the preferred solution would seem to be to take steps to
make our app insensitive to thread timing jitter. But 100 ms.
seems like a long time for a thread to be blocked even for a low
priority thread.
Wayne
On Dec 30, 2005, at 1:42 PM, Jeff Moore wrote:
This sounds like your work thread is getting out competed by other
threads on the system. What priority are you giving it?
On Dec 30, 2005, at 11:25 AM, Wayne Anderson wrote:
Our app currently is using an NSThread to run a timing loop that
gets events from a Music Sequence. These events are then passed
on to an internal processor that fills an internal buffer with
samples. The Core Audio render thread then draws from this
buffer on each render call. This scheme works fine on a dual
processor G5 but on a 1.67 MHz PowerBook our internal NSThread
occasionally gets blocked for a very long time (long in computer
terms at least) on the order of 100 milliseconds. The block
always seems to coincide with the Core Audio render thread
grabbing processor time. The only thing we are doing on the
render thread is calling memcpy to move data to the supplied
ABL. Setting the priority on the NSThread seems to make no
difference.
Is this kind of long blocking behavior normal?
Should we resort to a posix thread, or should we make use of ring
buffers or some other construct to process our events ahead of
time to make the app insensitive to this kind of thread timing
jitter.
--
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