Re: IOProc limitations
Re: IOProc limitations
- Subject: Re: IOProc limitations
- From: Jeff Moore <email@hidden>
- Date: Tue, 19 Jun 2001 12:34:23 -0700
on 6/19/01 12:22 PM, James McCartney <email@hidden> wrote:
>
Just to get back to this. If OSX did the proper priority inversion like a
>
good real time OS, then blocking the IOProc on a mutex would have no ill
>
effects. What would happen is that you would immediately switch to the
>
thread holding the lock, it could do its thing and release the lock, then
>
you would switch back to the IOProc. It would cost two thread switches, but
>
otherwise it would be just like a function call and the IOProc would
>
continue without problem.
The fundamental flaw with this logic is that even if the OS implemented
passing off the priority of one thread to another via locks, there is no
guarantee that the thread you would like to run will actually run. All
you've done is boosted it's priority over a short period of time. It then
has to compete with the other threads on the system, including other audio
threads. Sometimes it will work the way you want, sometimes it won't. Any
other process that does so much as a SysBeep() will potentially hose you.
Another issue is that any scheme relying on this kind of thing to work
properly will never scale well to multiple processors. The reason why is
that you are essentially tying two threads together as a single unit, which
effectively makes them a single thread.
This is a less than optimal situation no matter how you slice it. You are
better off coming up with a scheme that doesn't require a lock.
--
Jeff Moore
Core Audio
Apple