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
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
