Wed, Feb 15, 2023 at 06:01:46PM +0100, Klaus Schmidinger wrote:
On 22.01.23 13:52, Marko Mäkelä wrote:
Hi,
I would propose the following patch, or some equivalent interface that would allow cThread::mutex to be used with some cCondVar in derived classes:
diff --git a/thread.h b/thread.h index 16c4bd75..cd1d98ab 100644 --- a/thread.h +++ b/thread.h @@ -83,7 +83,9 @@ private: bool running; pthread_t childTid; tThreadId childThreadId; +protected: cMutex mutex; +private: char *description; bool lowPriority; static tThreadId mainThreadId;
I don't like the idea of exposing that mutex. If you really need such functionality, please suggest a function that does this without exposing the mutex.
An alternative might be to add a member functions to cThread that would take a cCondVar& as a parameter and invoke it with the private cThread::mutex. But, we can disregard this idea; see below.
[snip]
I did not complete the change to rpihddevice cOmx::Action() yet. We may be forced to retain two mutexes after all
You want to expose the cThread::mutex in order to avoid an additional mutex in the derived class, but may be forced to retain two mutexes after all - what am I missing here?
Meanwhile, I concluded that the only option is to have two mutexes in the rpihddevice class cOmx. The cThread::mutex makes calls to the ilclient and OMX thread-safe, and a private mutex of cOmx protects data in callback functions that may be invoked from other threads of that external library. An attempt to acquire the cThread::mutex in the callback code would lead to a deadlock.
It looks like a simple way to reduce the number of system calls in the plugin is to use the POSIX standard pthread_mutex_t and pthread_cond_t directly, or via the C++11 std::mutex and std::condition_variable. So, there is no pressing need to change anything in the VDR core.
Marko