[xiph-commits] r3755 - libsydneyaudio/trunk/src

[j at svn.annodex.net]

Author: j
Date: 2008-10-29 11:20:49 -0700 (Wed, 29 Oct 2008)
New Revision: 3755

Modified:
   libsydneyaudio/trunk/src/sydney_audio_mac.c
Log:
fix possible deadlock in os x backend in destroy, pause, and resume(fixes #432)



Modified: libsydneyaudio/trunk/src/sydney_audio_mac.c
===================================================================
--- libsydneyaudio/trunk/src/sydney_audio_mac.c	2008-10-29 18:18:23 UTC (rev 3754)
+++ libsydneyaudio/trunk/src/sydney_audio_mac.c	2008-10-29 18:20:49 UTC (rev 3755)
@@ -260,10 +260,15 @@
     return SA_SUCCESS;
   }
 
-  pthread_mutex_lock(&s->mutex);
-
   /*
-   * Shut down the audio output device.
+   * Shut down the audio output device.  Don't hold the mutex when stopping
+   * the audio device, because it is possible to deadlock with this thread
+   * holding mutex then waiting on an internal Core Audio lock, and with the
+   * callback thread holding the Core Audio lock and waiting on the mutex.
+   * This does not need to be protected by the mutex anyway because
+   * AudioOutputUnitStop, when called from the non-callback thread, blocks
+   * until in-flight callbacks complete and the HAL shuts down.  See:
+   * http://lists.apple.com/archives/coreaudio-api/2005/Dec/msg00055.html
    */
   int result = SA_SUCCESS;
   if (s->output_unit != NULL) {
@@ -278,8 +283,6 @@
     }
   }
 
-  pthread_mutex_unlock(&s->mutex);
-
   /*
    * Release resources.
    */
@@ -546,9 +549,14 @@
     return SA_ERROR_NO_INIT;
   }
 
-  pthread_mutex_lock(&s->mutex);
+  /*
+   * Don't hold the mutex when stopping the audio device, because it is
+   * possible to deadlock with this thread holding mutex then waiting on an
+   * internal Core Audio lock, and with the callback thread holding the Core
+   * Audio lock and waiting on the mutex.
+  */
   AudioOutputUnitStop(s->output_unit);
-  pthread_mutex_unlock(&s->mutex);
+
   return SA_SUCCESS;
 }
 
@@ -561,15 +569,21 @@
   }
 
   pthread_mutex_lock(&s->mutex);
-
   /*
    * The audio device resets its mSampleTime counter after pausing,
    * so we need to clear our tracking value to keep that in sync.
    */
   s->bytes_played = 0;
+  pthread_mutex_unlock(&s->mutex);
+
+  /*
+   * Don't hold the mutex when starting the audio device, because it is
+   * possible to deadlock with this thread holding mutex then waiting on an
+   * internal Core Audio lock, and with the callback thread holding the Core
+   * Audio lock and waiting on the mutex.
+  */
   AudioOutputUnitStart(s->output_unit);
 
-  pthread_mutex_unlock(&s->mutex);
   return SA_SUCCESS;
 }