Re: threading questions
Re: threading questions
- Subject: Re: threading questions
- From: Jeff Moore <email@hidden>
- Date: Mon, 10 Nov 2003 12:33:21 -0800
On Nov 8, 2003, at 4:03 PM, Matthew D Hancher wrote:
Hi. I'm writing a multi-channel audio app using the HAL. I need to be
able to support things like devices being unplugged or reconfigured
while my app is running, so I'm registered as a listener for all sorts
of notifications. Now I'm going through and trying to make my app
properly thread-safe, but I'm not seeing any documentation of how
the HAL works from a threading perspective.
The main reason for this is that you should not assume anything about
the thread context in which you are called. It could be a normal
priority user thread, a time constraint thread, or what have you. The
thread context involved depends as much on the driver for the device as
it does on what the callback is about.
The best advice is to minimize the amount work you have to do and to do
it as quickly as possible when called.
I have seen contradictory answers to even simple questions, such as
whether it is acceptable to use locks in my IOProc.
I wouldn't say that it is totally unacceptable to use a lock in an
IOProc, but it does have some significant drawbacks since your IOProc
has only a set amount of time, as determined by the rate scalar of the
device and the size of the IO buffers, to execute. If it fails to meet
the deadline, you will get a glitch of some sort. Unless you are being
very careful with how any locks are used, it is very easy to end up
blocking in the IOProc long enough to miss the deadline.
I have been using
non-locking circular buffers, but I'm trying to minimize latency and
so this extra layer of buffering is a little annoying. In what
context is the my IOProc really being called? Is it at hard interrupt
time, is it in the bottom half of an ISR, or is it in a totally
separate thread that does its own circular buffering to the ISR?
Like I said above, nothing about the context is guaranteed, but in the
current implementation for most drivers, your IOProc is being called
from a time constraint thread with a deadline enforced by the code that
is calling your IOProc. This brings up another drawback to blocking in
the IOProc, even for only a few microseconds. Namely, the scheduler
will get confused because the behavior of the thread isn't matching the
behavior the scheduler was told the thread would have.
If I
do block every once in a while while attempting to acquire a lock,
will the drivers notice and try to be "clever" by increasing some
internal buffer size to reduce the odds of future failures and thus
increase my latency?
Nope. These deadlines are hard and fast. If you miss one by blocking,
the following things happen: first you will receive a notification on
kAudioDeviceProcessorOverload, then the HAL will resynch with the
hardware by taking a full IO cycle sleep period, and you will get a
glitch in your IO.
Next, how do the listener callbacks fit in? Are these also called by
something like an ISR bottom half?
See above. There are no guarantees about what thread you will be called
on. It varies by the property that is changing as well as the driver
involved and where the change is coming from.
Can they interrupt an IOProc or vice versa?
Unless one were to configure kAudioHardwarePropertyRunLoop in a very
odd way, it isn't likely that another thread would interrupt your
IOProc to deliver notifications, but if you were to call back into the
HAL to change some state of the device from inside your IOProc, there
is every likelihood that your listener procs will get called while your
IOProc is executing.
For that matter, can one IOProc interrupt another IOProc?
For most drivers, there is only one thread per device per process. So,
multiple IOProcs on the same device will not interrupt each other. But
if each IOProc is attached to a different device, then it is possible
for the threads to interrupt each other if your IOProc takes long
enough to execute.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.