• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: AUGraph deadlocks
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AUGraph deadlocks


  • Subject: Re: AUGraph deadlocks
  • From: patrick machielse <email@hidden>
  • Date: Fri, 02 Dec 2011 21:25:26 +0100

So, is the implementation wrong, is the documentation wrong, or is my interpretation wrong…?

Or in other words: should I file a bug report?

Which AUGraph API _is_ safe to use?

I'm using AUGraphNodeInfo() to fetch unit instances from the graph before changing their parameters. Should I cache naked unit pointers instead of the nodes?

Thanks,

patrick
--
Patrick Machielse
Hieper Software

http://www.hieper.nl
email@hidden


Op 2 dec. 2011, om 21:09 heeft Doug Wyatt het volgende geschreven:

> AUGraphNodeInfo is (obviously) taking a lock and so it shouldn't be called on the audio render thread. I'd suggest fetching and caching whatever information you need from it beforehand.
>
>
> On Dec 2, 2011, at 8:01 , patrick machielse wrote:
>
>> In my app I'm using an AUGraph. This graph can be manipulated / inspected from both the audio rendering thread and the main thread.
>>
>> Occasionally I encounter deadlocks like this:
>>
>> ** MAIN THREAD **
>> #0  0x9ac29876 in __psynch_mutexwait ()
>> #1  0x93bfb6af in pthread_mutex_lock ()
>> #2  0x92698cae in HALB_Mutex::Lock ()
>> #17 0x0002d05b in ** MY_CODE **
>>
>> ** AUDIO THREAD **
>> #0  0x9ac29876 in __psynch_mutexwait ()
>> #1  0x93bfb6af in pthread_mutex_lock ()
>> #2  0x9851ba87 in CAMutex::Lock ()
>> #3  0x98534958 in AUGraphGetNodeInfo_Imp ()
>> #4  0x98534a95 in AUGraphNodeInfo ()
>> #5  0x0002b612 in getUnitByNode [inlined] () ** MY_CODE **
>>
>>
>> In the documentation on AUGraph I found the following statement:
>>
>> "A graph object’s state can be manipulated in both the rendering thread and in other threads. Consequently, any activities that affect the state of the graph are guarded with locks and a messaging model between any calling thread and the thread upon which the graph object’s output unit is called (the render thread)."
>>
>> I think it means that it calling AUGraphNodeInfo() and AUGraphStop() should be allowed, and that locking is handled by the framework. However, it seems not to work that way...
>>
>> Should I synchronize all graph access?

 _______________________________________________
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

  • Follow-Ups:
    • Re: AUGraph deadlocks
      • From: Brian Willoughby <email@hidden>
References: 
 >AUGraph deadlocks (From: patrick machielse <email@hidden>)
 >Re: AUGraph deadlocks (From: Doug Wyatt <email@hidden>)

  • Prev by Date: Re: AUGraph deadlocks
  • Next by Date: Re: AUGraph deadlocks
  • Previous by thread: Re: AUGraph deadlocks
  • Next by thread: Re: AUGraph deadlocks
  • Index(es):
    • Date
    • Thread