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 Kay <email@hidden>
- Date: Mon, 24 Apr 2006 15:56:05 -0400
on 4/24/06 11:38 AM, George Warner at email@hidden wrote:
> More or less. These "old school" timers API have been depreciated. These
> days I'd write this as an MP task (see <Multiprocessing.h>) with a loop that
> has a 1 mSec delay in it:
[snip]
Thanks much for that example.
Just an OT question: when something is "deprecated", does that mean it will
officially go away eventually? Or it may stick around, but its use is
"discouraged"? The Timer stuff seems to be working fine.
>> My guess is that the execution of the DeferredQueue that handles GUI
>> updating etc. (the main app thread) is able to be interrupted by the Mac OSX
>> at any time (in a different way than what happens on OS9). So the main
>> thread apparently suspends activity while in the middle of redrawing, leaves
>> the lockoutFlag set to true, and then the interrupt level thread cannot
>> perform any more tasks. And the status of the flag somehow gets confused. Or
>> something like that. Or maybe not.
>
> In Mac OS 9 those interrupt timers effectively disabled interrupts until the
> callback routine completed and returned. You could more-or-less assume that
> they would run to completion so you didn't have to code any more elaborate
> locks. On Mac OS X these are implemented in threads that can be preempted
> before completion. So you have to use real atomic locks.
[snip]
I think you have hit on my main problem here: the fact that my "interrupt"
level callback runs to completion on OS9, and doesn't on OS X. That would
probably be where my lockout flag is getting hung/confused. Previously, it
was not possible for this to halt in the middle and have the machine go off
and do something else.
Secondly, it's been easy for me to forget that what I consider my aging
needs-to-be-replaced G4 is actually a Dual 800 machine. So, as Stephen David
pointed out, I'm probably running the deferred thread at the same time as
the "interrupt" thread. In addition to the fact that my interrupt callback
does not run to completion anymore. Yikes.
> My guess is that the least amount of work would be to switch to using a real
> thread safe lock (like a semaphore) or a critical region. The
> Multiprocessing API's also include a thread safe queue (FIFO). If that's
> what you're trying to protect with the lock then you could switch to MP
> queue and eliminate the lock altogether. ;-)
Said in Arnold voice: "I'll be back".
Thanks to everyone that responded on this issue - lots of good
advice/suggestions!
- Stephen
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Stephen Kay
Karma Lab - developers of KARMA
http://www.karma-lab.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
_______________________________________________
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