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: Sun, 23 Apr 2006 23:37:47 -0400
on 4/23/06 11:01 PM, Kurt Revis at email@hidden wrote:
> First of all, if you haven't read this document, please do:
> http://developer.apple.com/documentation/Cocoa/Conceptual/
> Multithreading/index.html
Yep, been trying to digest it.
>> and having it process a list of queued tasks stored in a linked list
>> according to execution time (the "ScheduledQueue") - for my purposes, this is
>> used to generate MIDI data in real-time to create algorithmic music.
>
> Are you sure you need to do this exactly the same way in OS X? You
> can tell CoreMIDI to send a MIDI packet at a scheduled time in the
> future, and let it (and the MIDI hardware drivers) do the hard work
> of getting the timing accurate.
Maybe I could, maybe I couldn't, but it's a really complex system of
realtime MIDI generation, with things being scheduled, unscheduled,
referring to each other (even when already in the queue), added to the queue
and removed sometimes, etc. Maybe the current OS could do some (or all) of
this for me (now), but it seems far easier to simply get a 1 ms callback
happening and use all of my code that's been working and tested for 12
years, than to try and rewrite the whole thing.
> I bet you could get away with waking up far less frequently, which is
> easier to do reliably. Are you reacting to external input in order
> to figure out what MIDI to generate? How often does that input come
> in, and what is it (MIDI input, keyboard/mouse, network, ...)?
The whole thing works on a 1 ms clock. MIDI data comes in (from multiple
sources on a MIDI setup, keyboards, whatever), gets stored in circular
buffers, any queued up data gets read out every 1ms after the waiting tasks
are processed in the ScheduledQueue, etc.
>> There is a mechanism to set a "lockoutFlag" around "critical
>> sections" of
>> code that you don't want interrupted for any reason. The lockout flag
>> prevents interrupts while it is set to true.
>
> What is your "lockoutFlag" exactly? Just a variable in memory that
> you set to true during your critical section? Or is there some
> function you have to call to change it?
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.
> Anyway, on OS X, user code can't turn off interrupts for the whole
> machine, and can't prevent itself from being preempted. The system is
> fully preemptive, and any of your code may be preempted at any time.
> (You can give hints to the scheduler to try to change its behavior,
> but it is free to ignore you.)
>
> Turning off interrupts for the whole machine was almost certainly
> total overkill, even under OS 9.
No, this isn't what I was doing, I don't think. The lockout flag was a way
to prevent an interrupt from interrupting one that's already being handled.
It seems pretty analogous to a CriticalSection/Mutex thing that I've been
reading about.
> You can't do it anymore anyway, so
> you need to determine what it is that you really want to achieve.
> Probably, you want a guarantee that one thread not run while the
> other one is in the critical section ... but I'm just guessing, you
> need to figure out the exact details.
>
> If that is what you want, you'd set up a "mutex lock",
[snip]
Thanks, I've been fooling with that, so far no luck, but I'm probably doing
it wrong. Will check more.
>> 2. I don't even know what kind of threading this is, now that its
>> on Mach-O.
>
> I don't know what these ancient Time Manager functions do either. As
> a start, set a breakpoint in your timer callback and see what thread
> it's in when it gets hit. I assume it will be a different thread
> than the main thread (one that Carbon started for you) but it's
> important to actually know.
Yes, I've done this. It's definitely a separate thread. On both OS9 and
Mach-O.
>> 3. On another front, I see that this whole method of doing things
>> has been
>> deprecated (or has it?). The Time Manager Reference says
>> "Deprecated. Use
>> Carbon Event Loop timers or Cocoa NSTimers instead."
>
> I don't know how much clearer it could be. Yes, this stuff is
> incredibly deprecated. I haven't heard of anybody using it in years.
Yeah, except if you start reading about Carbon Event Loop Timers etc., they
make them sound rather inaccurate. They even say something about "don't
confuse these with timers." Well heck, I want a timer, preferably
rock-solid.
All I know is I've got my incredibly ancient 1ms clock running perfectly
fine in Mach-O. Timing sounds very solid (haven't quantitatively analyzed it
yet). Just this problem with the flag getting stuck. Or maybe more problems
that I don't know about yet. ;-)
But maybe there's a better way to do it. I've been pointed to the concept of
creating a POSIX thread with "real time priority scheduling", but I haven't
figured out how to integrate that yet. I just want some function to call me
every 1 ms.
Thanks,
- 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