Re: [PATCH] Use cThread::mutex with absolute cCondVar::TimedWait()

Wed, Feb 15, 2023 at 06:01:46PM +0100, Klaus Schmidinger wrote:
>On 22.01.23 13:52, Marko M=E4kel=E4 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:
>> =A0=A0 bool running;
>> =A0=A0 pthread_t childTid;
>> =A0=A0 tThreadId childThreadId;
>>+protected:
>> =A0=A0 cMutex mutex;
>>+private:
>> =A0=A0 char *description;
>> =A0=A0 bool lowPriority;
>> =A0=A0 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
[email protected]
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr