Re: What is causing this deadlock?
Re: What is causing this deadlock?
- Subject: Re: What is causing this deadlock?
- From: Jeff Moore <email@hidden>
- Date: Mon, 28 Jan 2008 12:24:54 -0800
Sorry this took so long. At any rate, enough info made it through that
I got a good sense of what's going on.
The first thing I want to say is that you should file this in Radar.
This appears to be a deadlock in the HAL that I'd like to look at a
bit closer.
That said, my first thought would be to ask why are you are using hog
mode in the first place? Most apps that think they need hog mode,
don't really need it at all. Judging from the name of your app
(MacSpeech Dictate Medical), it doesn't seem to me that your app would
need to use hog mode for anything.
My second thought is that it appears that you've pointed the HAL at
your main thread to use for notifications. It turns out that having
Cocoa and the HAL share this thread is not a good idea. Cocoa can
monopolize that thread way too easily to make it useful as the HAL's
notification thread. Cocoa apps should really just let the HAL manage
it's own notification thread. It's possible that this may clear up
this deadlock, but it may just move it to being between the
notification thread and your worker thread that is releasing hog mode.
On Jan 25, 2008, at 1:54 PM, Bob Stuller wrote:
Sorry that I had to edit the hang report following the body of the
email. The list server draws the line at 12k.
Jeff, Greetings!
At 12:05 PM -0800 1/25/08, Jeff Moore wrote:
Every so often the problem arises right after we've taken hog mode
successfully. You can see in the stack of the work thread:
AudioDeviceSetProperty >> HALObject::SetPropertyData >>
HALPlugIn::ObjectSetPropertyData >>
IOA_SingleDevice::SetPropertyData >> HP_HogMode::Take >>
IOA_SingleDevice::HogModeStateChanged >> CAMutex::Lock >>
pthread_mutex_lock >> semaphore_wait_signal_trap
Over on the main thread, you see the following in the stack:
CFRunLoopRunSpecific >> __CFMachPortPerform >>
IOA_HWDevice::MachPortCallBack >>
IOA_SingleDevice::HWDevice_FormatChanged >> CAMutex::Lock >>
pthread_mutex_lock >> semaphore_wait_signal_trap
Can you post a sample trace with the full backtraces?
Edited at the end of this email.
Thanks for looking this over. As I had noted, I was basing my
questions partially on conjecture.
Some questions that occurred to me, partially based on conjecture:
Why is the IOA_SingleDevice notifying itself?
Not sure what you mean. The HAL is written in C++ and the back
trace just shows the control flow moving between various
implementation objects.
There are 2 back-traces here. The non-BlueTask thread's back-trace
has an IOA_SingleDevice whose HogModeStateChanged method locks the
mutex.
Now, as you point out, it might just be a coincidence, that the main
thread is calling into a HWDevice's MachPortCallBack which in turn
calls into a IOA_SingleDevice also & that object instance (indeed,
there is no way to tell that it's the same instance of
IOA_SingleDevice) has its method FormatChanged called, which is also
calling CAMutex::Lock.
Why is Hog mode being notified as a format change?
It is not. You are presuming that the two are related rather than
just coincidental.
You are absolutely right that I am working in the dark here. No
source code to look at, I have to infer things as best I can. If I
had the source code I would know if the two IOA_SingleDevice
instances are in fact the same instance. Further, I would be able
to tell whether IOA_SingleDevice uses the same CAMutex instance for
both HogModeStateChanged & FormatChanged.
But this pair of stack crawls is repeatable. I have a bunch from
the beta-testers too. So it is more than cosmic-ray random.
I have a possibly related question. I've set the BlueTask run-loop
as the preferred place to receive notifications from Core Audio. At
the point in time that this occurs I only have two listeners, one on
the hardware to hear about changes to the list of input devices &
'DeviceIsAlive' on the device that we're soon going to be pulling
audio from. Will other notifications occur on that run loop without
a callback being registered for them?
Is the same CAMutex instance used in both IOA_SingleDevice
methods? What am I doing wrong?
Hard to say without more context.
A more complete hang report follows my signature. Thank you for
taking the time to look this over.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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