mirrors/gstreamer
mirrors/gstreamer
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2024-09-21 11:30:18 +00:00
Code Issues 1 Projects Releases Wiki Activity
gstreamer/omx/gstomxrecmutex.c

98 lines
2.5 KiB
C
Raw Normal View History

Implement a new custom recursive mutex type and fix locking in callbacks so that in-context calls are allowed. According to the OMX specification, implementations are allowed to call callbacks in the context of their function calls. However, our callbacks take locks and this causes deadlocks if the unerlying OMX implementation uses this kind of in-context calls. A solution to the problem would be a recursive mutex. However, a normal recursive mutex does not fix the problem because it is not guaranteed that the callbacks are called from the same thread. What we see in Broadcom's implementation for example is: - OMX_Foo is called - OMX_Foo waits on a condition - A callback is executed in a different thread - When the callback returns, its calling function signals the condition that OMX_Foo waits on - OMX_Foo wakes up and returns The solution I came up with here is to take a second lock inside the callback, but only if recursion is expected to happen. Therefore, all calls to OMX functions are guarded by calls to gst_omx_rec_mutex_begin_recursion() / _end_recursion(), which effectively tells the mutex that at this point we want to allow calls to _recursive_lock() to succeed, although we are still holding the master lock.
2012-04-30 20:58:43 +00:00
/*
* Copyright (C) 2012, Collabora Ltd.
* Author: George Kiagiadakis <george.kiagiadakis@collabora.com>
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation
* version 2.1 of the License.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*
*/
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include "gstomxrecmutex.h"
void
gst_omx_rec_mutex_init (GstOMXRecMutex * mutex)
{
omx: Update to new GLib thread API
2012-11-12 10:29:48 +00:00
g_mutex_init (&mutex->lock);
g_mutex_init (&mutex->recursion_lock);
Implement a new custom recursive mutex type and fix locking in callbacks so that in-context calls are allowed. According to the OMX specification, implementations are allowed to call callbacks in the context of their function calls. However, our callbacks take locks and this causes deadlocks if the unerlying OMX implementation uses this kind of in-context calls. A solution to the problem would be a recursive mutex. However, a normal recursive mutex does not fix the problem because it is not guaranteed that the callbacks are called from the same thread. What we see in Broadcom's implementation for example is: - OMX_Foo is called - OMX_Foo waits on a condition - A callback is executed in a different thread - When the callback returns, its calling function signals the condition that OMX_Foo waits on - OMX_Foo wakes up and returns The solution I came up with here is to take a second lock inside the callback, but only if recursion is expected to happen. Therefore, all calls to OMX functions are guarded by calls to gst_omx_rec_mutex_begin_recursion() / _end_recursion(), which effectively tells the mutex that at this point we want to allow calls to _recursive_lock() to succeed, although we are still holding the master lock.
2012-04-30 20:58:43 +00:00
mutex->recursion_allowed = FALSE;
}
void
gst_omx_rec_mutex_clear (GstOMXRecMutex * mutex)
{
omx: Update to new GLib thread API
2012-11-12 10:29:48 +00:00
g_mutex_clear (&mutex->lock);
g_mutex_clear (&mutex->recursion_lock);
Implement a new custom recursive mutex type and fix locking in callbacks so that in-context calls are allowed. According to the OMX specification, implementations are allowed to call callbacks in the context of their function calls. However, our callbacks take locks and this causes deadlocks if the unerlying OMX implementation uses this kind of in-context calls. A solution to the problem would be a recursive mutex. However, a normal recursive mutex does not fix the problem because it is not guaranteed that the callbacks are called from the same thread. What we see in Broadcom's implementation for example is: - OMX_Foo is called - OMX_Foo waits on a condition - A callback is executed in a different thread - When the callback returns, its calling function signals the condition that OMX_Foo waits on - OMX_Foo wakes up and returns The solution I came up with here is to take a second lock inside the callback, but only if recursion is expected to happen. Therefore, all calls to OMX functions are guarded by calls to gst_omx_rec_mutex_begin_recursion() / _end_recursion(), which effectively tells the mutex that at this point we want to allow calls to _recursive_lock() to succeed, although we are still holding the master lock.
2012-04-30 20:58:43 +00:00
}
void
gst_omx_rec_mutex_lock (GstOMXRecMutex * mutex)
{
omx: Update to new GLib thread API
2012-11-12 10:29:48 +00:00
g_mutex_lock (&mutex->lock);
Implement a new custom recursive mutex type and fix locking in callbacks so that in-context calls are allowed. According to the OMX specification, implementations are allowed to call callbacks in the context of their function calls. However, our callbacks take locks and this causes deadlocks if the unerlying OMX implementation uses this kind of in-context calls. A solution to the problem would be a recursive mutex. However, a normal recursive mutex does not fix the problem because it is not guaranteed that the callbacks are called from the same thread. What we see in Broadcom's implementation for example is: - OMX_Foo is called - OMX_Foo waits on a condition - A callback is executed in a different thread - When the callback returns, its calling function signals the condition that OMX_Foo waits on - OMX_Foo wakes up and returns The solution I came up with here is to take a second lock inside the callback, but only if recursion is expected to happen. Therefore, all calls to OMX functions are guarded by calls to gst_omx_rec_mutex_begin_recursion() / _end_recursion(), which effectively tells the mutex that at this point we want to allow calls to _recursive_lock() to succeed, although we are still holding the master lock.
2012-04-30 20:58:43 +00:00
}
void
gst_omx_rec_mutex_unlock (GstOMXRecMutex * mutex)
{
omx: Update to new GLib thread API
2012-11-12 10:29:48 +00:00
g_mutex_unlock (&mutex->lock);
Implement a new custom recursive mutex type and fix locking in callbacks so that in-context calls are allowed. According to the OMX specification, implementations are allowed to call callbacks in the context of their function calls. However, our callbacks take locks and this causes deadlocks if the unerlying OMX implementation uses this kind of in-context calls. A solution to the problem would be a recursive mutex. However, a normal recursive mutex does not fix the problem because it is not guaranteed that the callbacks are called from the same thread. What we see in Broadcom's implementation for example is: - OMX_Foo is called - OMX_Foo waits on a condition - A callback is executed in a different thread - When the callback returns, its calling function signals the condition that OMX_Foo waits on - OMX_Foo wakes up and returns The solution I came up with here is to take a second lock inside the callback, but only if recursion is expected to happen. Therefore, all calls to OMX functions are guarded by calls to gst_omx_rec_mutex_begin_recursion() / _end_recursion(), which effectively tells the mutex that at this point we want to allow calls to _recursive_lock() to succeed, although we are still holding the master lock.
2012-04-30 20:58:43 +00:00
}
/* must be called with mutex->lock taken */
void
gst_omx_rec_mutex_begin_recursion (GstOMXRecMutex * mutex)
{
omx: Update to new GLib thread API
2012-11-12 10:29:48 +00:00
g_mutex_lock (&mutex->recursion_lock);
Implement a new custom recursive mutex type and fix locking in callbacks so that in-context calls are allowed. According to the OMX specification, implementations are allowed to call callbacks in the context of their function calls. However, our callbacks take locks and this causes deadlocks if the unerlying OMX implementation uses this kind of in-context calls. A solution to the problem would be a recursive mutex. However, a normal recursive mutex does not fix the problem because it is not guaranteed that the callbacks are called from the same thread. What we see in Broadcom's implementation for example is: - OMX_Foo is called - OMX_Foo waits on a condition - A callback is executed in a different thread - When the callback returns, its calling function signals the condition that OMX_Foo waits on - OMX_Foo wakes up and returns The solution I came up with here is to take a second lock inside the callback, but only if recursion is expected to happen. Therefore, all calls to OMX functions are guarded by calls to gst_omx_rec_mutex_begin_recursion() / _end_recursion(), which effectively tells the mutex that at this point we want to allow calls to _recursive_lock() to succeed, although we are still holding the master lock.
2012-04-30 20:58:43 +00:00
g_assert (mutex->recursion_allowed == FALSE);
mutex->recursion_allowed = TRUE;
omx: Update to new GLib thread API
2012-11-12 10:29:48 +00:00
g_mutex_unlock (&mutex->recursion_lock);
Implement a new custom recursive mutex type and fix locking in callbacks so that in-context calls are allowed. According to the OMX specification, implementations are allowed to call callbacks in the context of their function calls. However, our callbacks take locks and this causes deadlocks if the unerlying OMX implementation uses this kind of in-context calls. A solution to the problem would be a recursive mutex. However, a normal recursive mutex does not fix the problem because it is not guaranteed that the callbacks are called from the same thread. What we see in Broadcom's implementation for example is: - OMX_Foo is called - OMX_Foo waits on a condition - A callback is executed in a different thread - When the callback returns, its calling function signals the condition that OMX_Foo waits on - OMX_Foo wakes up and returns The solution I came up with here is to take a second lock inside the callback, but only if recursion is expected to happen. Therefore, all calls to OMX functions are guarded by calls to gst_omx_rec_mutex_begin_recursion() / _end_recursion(), which effectively tells the mutex that at this point we want to allow calls to _recursive_lock() to succeed, although we are still holding the master lock.
2012-04-30 20:58:43 +00:00
}
/* must be called with mutex->lock taken */
void
gst_omx_rec_mutex_end_recursion (GstOMXRecMutex * mutex)
{
omx: Update to new GLib thread API
2012-11-12 10:29:48 +00:00
g_mutex_lock (&mutex->recursion_lock);
Implement a new custom recursive mutex type and fix locking in callbacks so that in-context calls are allowed. According to the OMX specification, implementations are allowed to call callbacks in the context of their function calls. However, our callbacks take locks and this causes deadlocks if the unerlying OMX implementation uses this kind of in-context calls. A solution to the problem would be a recursive mutex. However, a normal recursive mutex does not fix the problem because it is not guaranteed that the callbacks are called from the same thread. What we see in Broadcom's implementation for example is: - OMX_Foo is called - OMX_Foo waits on a condition - A callback is executed in a different thread - When the callback returns, its calling function signals the condition that OMX_Foo waits on - OMX_Foo wakes up and returns The solution I came up with here is to take a second lock inside the callback, but only if recursion is expected to happen. Therefore, all calls to OMX functions are guarded by calls to gst_omx_rec_mutex_begin_recursion() / _end_recursion(), which effectively tells the mutex that at this point we want to allow calls to _recursive_lock() to succeed, although we are still holding the master lock.
2012-04-30 20:58:43 +00:00
g_assert (mutex->recursion_allowed == TRUE);
mutex->recursion_allowed = FALSE;
omx: Update to new GLib thread API
2012-11-12 10:29:48 +00:00
g_mutex_unlock (&mutex->recursion_lock);
Implement a new custom recursive mutex type and fix locking in callbacks so that in-context calls are allowed. According to the OMX specification, implementations are allowed to call callbacks in the context of their function calls. However, our callbacks take locks and this causes deadlocks if the unerlying OMX implementation uses this kind of in-context calls. A solution to the problem would be a recursive mutex. However, a normal recursive mutex does not fix the problem because it is not guaranteed that the callbacks are called from the same thread. What we see in Broadcom's implementation for example is: - OMX_Foo is called - OMX_Foo waits on a condition - A callback is executed in a different thread - When the callback returns, its calling function signals the condition that OMX_Foo waits on - OMX_Foo wakes up and returns The solution I came up with here is to take a second lock inside the callback, but only if recursion is expected to happen. Therefore, all calls to OMX functions are guarded by calls to gst_omx_rec_mutex_begin_recursion() / _end_recursion(), which effectively tells the mutex that at this point we want to allow calls to _recursive_lock() to succeed, although we are still holding the master lock.
2012-04-30 20:58:43 +00:00
}
void
gst_omx_rec_mutex_recursive_lock (GstOMXRecMutex * mutex)
{
omx: Update to new GLib thread API
2012-11-12 10:29:48 +00:00
g_mutex_lock (&mutex->recursion_lock);
Implement a new custom recursive mutex type and fix locking in callbacks so that in-context calls are allowed. According to the OMX specification, implementations are allowed to call callbacks in the context of their function calls. However, our callbacks take locks and this causes deadlocks if the unerlying OMX implementation uses this kind of in-context calls. A solution to the problem would be a recursive mutex. However, a normal recursive mutex does not fix the problem because it is not guaranteed that the callbacks are called from the same thread. What we see in Broadcom's implementation for example is: - OMX_Foo is called - OMX_Foo waits on a condition - A callback is executed in a different thread - When the callback returns, its calling function signals the condition that OMX_Foo waits on - OMX_Foo wakes up and returns The solution I came up with here is to take a second lock inside the callback, but only if recursion is expected to happen. Therefore, all calls to OMX functions are guarded by calls to gst_omx_rec_mutex_begin_recursion() / _end_recursion(), which effectively tells the mutex that at this point we want to allow calls to _recursive_lock() to succeed, although we are still holding the master lock.
2012-04-30 20:58:43 +00:00
if (!mutex->recursion_allowed) {
/* no recursion allowed, lock the proper mutex */
omx: Update to new GLib thread API
2012-11-12 10:29:48 +00:00
g_mutex_unlock (&mutex->recursion_lock);
g_mutex_lock (&mutex->lock);
Implement a new custom recursive mutex type and fix locking in callbacks so that in-context calls are allowed. According to the OMX specification, implementations are allowed to call callbacks in the context of their function calls. However, our callbacks take locks and this causes deadlocks if the unerlying OMX implementation uses this kind of in-context calls. A solution to the problem would be a recursive mutex. However, a normal recursive mutex does not fix the problem because it is not guaranteed that the callbacks are called from the same thread. What we see in Broadcom's implementation for example is: - OMX_Foo is called - OMX_Foo waits on a condition - A callback is executed in a different thread - When the callback returns, its calling function signals the condition that OMX_Foo waits on - OMX_Foo wakes up and returns The solution I came up with here is to take a second lock inside the callback, but only if recursion is expected to happen. Therefore, all calls to OMX functions are guarded by calls to gst_omx_rec_mutex_begin_recursion() / _end_recursion(), which effectively tells the mutex that at this point we want to allow calls to _recursive_lock() to succeed, although we are still holding the master lock.
2012-04-30 20:58:43 +00:00
}
}
void
gst_omx_rec_mutex_recursive_unlock (GstOMXRecMutex * mutex)
{
/* It is safe to check recursion_allowed here because
* we hold at least one of the two locks and
* either lock protects it from being changed.
*/
if (mutex->recursion_allowed) {
omx: Update to new GLib thread API
2012-11-12 10:29:48 +00:00
g_mutex_unlock (&mutex->recursion_lock);
Implement a new custom recursive mutex type and fix locking in callbacks so that in-context calls are allowed. According to the OMX specification, implementations are allowed to call callbacks in the context of their function calls. However, our callbacks take locks and this causes deadlocks if the unerlying OMX implementation uses this kind of in-context calls. A solution to the problem would be a recursive mutex. However, a normal recursive mutex does not fix the problem because it is not guaranteed that the callbacks are called from the same thread. What we see in Broadcom's implementation for example is: - OMX_Foo is called - OMX_Foo waits on a condition - A callback is executed in a different thread - When the callback returns, its calling function signals the condition that OMX_Foo waits on - OMX_Foo wakes up and returns The solution I came up with here is to take a second lock inside the callback, but only if recursion is expected to happen. Therefore, all calls to OMX functions are guarded by calls to gst_omx_rec_mutex_begin_recursion() / _end_recursion(), which effectively tells the mutex that at this point we want to allow calls to _recursive_lock() to succeed, although we are still holding the master lock.
2012-04-30 20:58:43 +00:00
} else {
omx: Update to new GLib thread API
2012-11-12 10:29:48 +00:00
g_mutex_unlock (&mutex->lock);
Implement a new custom recursive mutex type and fix locking in callbacks so that in-context calls are allowed. According to the OMX specification, implementations are allowed to call callbacks in the context of their function calls. However, our callbacks take locks and this causes deadlocks if the unerlying OMX implementation uses this kind of in-context calls. A solution to the problem would be a recursive mutex. However, a normal recursive mutex does not fix the problem because it is not guaranteed that the callbacks are called from the same thread. What we see in Broadcom's implementation for example is: - OMX_Foo is called - OMX_Foo waits on a condition - A callback is executed in a different thread - When the callback returns, its calling function signals the condition that OMX_Foo waits on - OMX_Foo wakes up and returns The solution I came up with here is to take a second lock inside the callback, but only if recursion is expected to happen. Therefore, all calls to OMX functions are guarded by calls to gst_omx_rec_mutex_begin_recursion() / _end_recursion(), which effectively tells the mutex that at this point we want to allow calls to _recursive_lock() to succeed, although we are still holding the master lock.
2012-04-30 20:58:43 +00:00
}
}
Reference in a new issue Copy permalink