Re: Threading/timer issues on Mach-O vs. OS 9
Re: Threading/timer issues on Mach-O vs. OS 9
- Subject: Re: Threading/timer issues on Mach-O vs. OS 9
- From: Matt Connolly <email@hidden>
- Date: Mon, 24 Apr 2006 20:25:23 +1000
on 4/24/06 1:24 AM, Kurt Revis at email@hidden wrote:
>> The lockout flag is a global variable. When the TimerProc is
>> called, every 1
>> ms, if the flag is "true" (locked), you exit and don't process any
>> Scheduled
>> Tasks.
>
> OK, so I'm confused about how this thing gets "stuck". If it's just
> a global variable that's completely under the control of your own
> code, you should be able to figure out what's going on, yes?
Nothing
> else in the system is going to touch it.
Yeah, you would think. But it hasn't been easy to track down so
far. It gets
set from numerous places. There's something going on with the
interaction of
these two threads that I haven't figured out yet, that works quite
differently from OS 9.
> Is this value a simple integer (long or int or whatever) or is it
> some larger structure?
It's just a Boolean.
> Hard to tell anything from just listening to the results -- I bet
> you're getting called back frequently, but the jitter is probably
> pretty high compared to your 1 ms period. Only measuring it will
tell
> you for sure. Last time I looked (2002 or so) the high level CF/
> NSTimers wouldn't get you anywhere near 1 ms. I don't know how
> Carbon simulates the Time Manager stuff, but it could well be
doing a
> better job.
Well, there must be some way to do it, because I think a number of
music
apps work this way. There's one I can think of, offhand, which is
Max/MSP,
I'd be interested to know what he's gone to in OS X. Because my
original
code is descended from the same type of scheduler used in that.
I've sent
him an email.
> Also -- and I know this is beyond the bounds of what you want to do
> right now -- I really recommend that you think about a redesign in
> the future. There's a considerable amount of overhead in making
your
> thread wake up 1000 times a second,
Compared to what? Certainly not to processing audio or video.
The amount of CPU time consumed by the kernel to do 1000 thread
switches a second will be significantly higher than the number of
thread switches required by a program like final cut which uses a
small number of threads to process large amounts of information at
not-so-frequent intervals.... i think that comment was all about the
overhead in switching threads, and not what the threads themselves
are doing. hence the point where it is best to not wake a sleeping
thread if there is no work to do.
> and it's especially pointless if
> you do nothing 99.9% of the time. It's entirely possible to get rid
> of all this overhead, and wake up your timer thread only when it has
> actual work to do.
Yeah, I hear what you're saying, but I don't know that a redesign is
required - yet. I'll cross that bridge later.
Try this for a suggestion:
Create one thread whose primary job is to sleep for 1ms and if
required, fire off a message to another thread for processing, (if
required!!!). I found that it was easier to use an atomic counter /
list and counting semaphores (much easier to program than mach-o
messages )in an application for some thread synchronisation which
worked well.
The second thread, which does the processing, and is only woken when
there is work to do does the work.
The nice thing about this is that the timing and the processing are
separated. This also means that if there is lots of processing to do,
the other thread can still stay on top of the timer stuff.
To be honest, though, i don't know too much about the accuracy of
something like usleep(). The man pages clearly state that the call my
sleep for longer depending on latencies, which could mean that the
jitter could compound and result in something like only 900 timer
fires in a second instead of 1000 - which i'm guessing is a big
problem for you....? Although you could measure the cpu time and
request to sleep until the next 1ms "tick" from your last time
reference... that way if the usleep() function was delayed, it will
request less sleep time on the next call to get back to a 1ms average
and 1000 calls a second.
Good luck!
Matt
_______________________________________________
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