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: Stephen Davis <email@hidden>
- Date: Mon, 24 Apr 2006 00:42:29 -0700
On Apr 23, 2006, at 11:57 PM, Stephen Kay wrote:
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.
Unlike OS 9, Deferred Tasks can run simultaneously with other threads
if you have more than one CPU. Both they and Timer Tasks are
implemented with higher-than-app fixed-priority pthreads so Timer
Tasks may run simultaneously with the main thread as well. This may
be what's biting you.
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.
You could use a pthread timed condition wait -- pthread_cond_timedwait
() -- with a 1ms timeout and just let it time out instead of
signaling it from some other thread. This will give you a good
resolution "timer" and is probably how the Timer Tasks are
implemented (I'm not on the OS team so I'm just assuming). Note that
these timed waits can sometime wake up spuriously for a variety of
reasons so you may want to structure the code so that it goes right
back to sleep if the sleep time is not yet used up.
As Kurt said though, a 1ms sleep time is pretty hard on the scheduler
so it'd be good to avoid such a small timeout if at all possible.
If I create a pthread mutex within the context of one thread, and
then lock
it from some other thread, am I locking the thread it was created
on, or the
thread I'm calling it from? I assume the former, but I just want to
make
sure.
A pthread mutex does not "lock a thread" but instead guards access to
a shared variable. A thread that wants to manipulate the shared
variable calls pthread_mutex_lock() to acquire exclusive access.
While a thread holds the lock, any _other_ thread that calls
pthread_mutex_lock() on the same mutex will block until the first
thread lets go of it. It doesn't matter what thread the mutex is
created on. That, of course, is an overly simplistic explanation of
pthread mutexes -- google for "butenhof pthreads" and enjoy the
overload of information...
hth,
stephen
_______________________________________________
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