Implement a new custom recursive mutex type and fix locking in callbacks so that...
authorGeorge Kiagiadakis <george.kiagiadakis@collabora.com>
Mon, 30 Apr 2012 20:58:43 +0000 (23:58 +0300)
committerGeorge Kiagiadakis <george.kiagiadakis@collabora.com>
Mon, 7 May 2012 14:01:16 +0000 (17:01 +0300)
commit158775f497d99dc6b0190e4a3e4bc3183f6961be
treeaf19afdd11c762b791f96e5e22306b77089bffba
parent5c15caef8eb772dd72b7564154d6f99cf9aa6f37
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.
omx/Makefile.am
omx/gstomx.c
omx/gstomx.h
omx/gstomxaudioenc.c
omx/gstomxrecmutex.c [new file with mode: 0644]
omx/gstomxrecmutex.h [new file with mode: 0644]
omx/gstomxvideodec.c
omx/gstomxvideoenc.c