Re: IOProc limitations
Re: IOProc limitations
- Subject: Re: IOProc limitations
- From: Jeff Moore <email@hidden>
- Date: Thu, 31 May 2001 17:44:05 -0700
on 5/31/01 5:17 PM, James McCartney <email@hidden> wrote:
>
on 5/30/01 9:24 PM, Jeff Moore at email@hidden wrote:
>
>
> The HAL doesn't touch other thread's priorities. It's IOThreads are Mach
>
> real-time threads. As such, they are the highest priority threads in the
>
> system, capable of pre-empting just about everything.
>
>
I had thought that OSX kernel did priority inversion, so that any thread
>
holding a mutex required by a high priority thread would get bumped to the
>
same priority. (not by the HAL but by the kernel scheduler.)
I'd refer to the source code in Darwin for this info. I couldn't tell you
offhand whether it does or not. But regardless, you _really_ ought not block
the IOThread on a mutex that some other thread may have. You will get very
bad results since the HAL will treat you as if you are CPU bound and you
will get lots of internal resynchs. In other words, you will get break up
and distortion.
The other nasty little side effect is that by using a mutex, you are
essentially making two threads behave as a single thread, which will be less
than optimal on an multiprocessor machine where both threads might want to
execute simultaneously. It is definitely worth the effort to clean up your
code so that it is possible to do this sort of thing.
>
> As a general rule, it is a really bad idea to stall the IOThread by waiting
>
> on a mutex or something like that. You'll really hose your timing if the
>
>
OK. But how do you sync your threads? If you cannot use a mutex then you
>
cannot implement a semaphore or a condition. It would seem that you would
>
only have polling to fall back on to check the ioproc's progress.
You need to use a lock-less synchronization scheme. How you would do
something like this totally depends on your code. In general, it means
making sure that everything your IOProc touches is prepared ahead of time
and knowing exactly what code paths will get invoked. It isn't easy, but it
can be done.
Bear in mind, that you don't need to be holding a mutex to signal on it's
associated condition variable (assuming you're using the PThread API). So if
you want to wake up another thread from your IOProc, you don't actually have
to take the mutex to signal the waiting thread. This should clear up just
about every instance where you might need to take a lock (it did in my own
code at least when I ported the Sound Manager).
Note that Java synchronization doesn't allow for this kind of thing. It
forces you to take the object lock before being allowed to signal, which
really sucks IMHO. You can work around this somewhat if you are willing to
write some native code. This is definitely something I'd like to address in
our Java interfaces at some point.
All that said, my debug builds of the HAL use fprintf extensively (mutexes
and file IO in the IOThread) and don't seem to introduce too many timing
anomalies or break up until I put a real load on the system. Then, I can
hear the occasional drop out. Your mileage may vary, but in general, our
system is robust enough that you should be able to get away with flipping
between mutexes in your IOProc, but you're definitely opening things up to a
world of hurt when the system gets stressed.
--
Jeff Moore
Core Audio
Apple