<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - pa_threaded_mainloop_stop() blocks on pa_mutex_lock(m->mutex)" href="https://bugs.freedesktop.org/show_bug.cgi?id=62529#c1">Comment # 1</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - pa_threaded_mainloop_stop() blocks on pa_mutex_lock(m->mutex)" href="https://bugs.freedesktop.org/show_bug.cgi?id=62529">bug 62529</a> from <a class="email" href="mailto:tanuk@iki.fi" title="Tanu Kaskinen <tanuk@iki.fi>"> Tanu Kaskinen</a> <pre>(In reply to <a href="show_bug.cgi?id=62529#c0">comment #0</a>) > I recently switched my pulseaudio code to pulseaudio-3.0 and used > pa_threaded_mainloop to use pulseaudio library in multi-threaded application. > I find in some cases, pa_threaded_mainloop_stop() will just block on > pa_mutex_lock(m->mutex) and never quit. > > I have read the source code of pa_threaded_mainloop_stop() > pa_threaded_mainloop_run(), it seems that there is one possibility that > makes this happen. > In pa_threaded_mainloop_run(), a thread is created and pa_mainloop_run is > called and protected by pa_mutex_lock(m->mutex) and > pa_mutex_unlock(m->mutex) in the thread; > > in pa_threaded_mainloop_stop(), pa_mainloop_quit is also protected by > pa_mutex_lock(m->mutex) and pa_mutex_unlock(m->mutex); > > So, here is the problem, in pa_threaded_mainloop_stop(), m->mutex must be > aquired before pa_mainloop_quit() can be called, and in > pa_threaded_mainloop_run(), I guess you mean pa_threaded_mainloop_start()? > when pa_mainloop_run() exits, m->mutex can be > unlocked. If pa_mainloop_run() is blocked, the only way to make > pa_mainloop_run() exit is to call pa_mainloop_quit(), but pa_mainloop_quit() > can only be called after pa_mainloop_run() is quit. > > This is the deadlock. I don't see the deadlock. At the beginning we have one thread, let's call it the main thread. It doesn't initially hold the lock. The main thread calls pa_threaded_mainloop_start(). That spawns a new thread, let's call it the helper thread. The main thread doesn't lock the mutex. When the helper thread starts, it will lock the mutex and call pa_mainloop_run(). The main thread calls pa_threaded_mainloop_stop(). This causes the main thread to lock the mutex. This is where your program deadlocks. Some other thread is holding the lock and won't release it. Is it the helper thread? No, because the helper thread will release the lock as soon as it enters polling. It will take the lock again when the polling ends, but there is no code that can block during the time the lock is held (except the callbacks that you provide, but that's then a bug in your code). So, the helper thread will always release the lock eventually, thus there's no deadlock. Have you checked with a debugger what other threads are blocking on the mutex, and what they are doing? Is the helper thread perhaps stuck in one of your callbacks?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>