[Interest] Which thread implementation is best to trigger external library via timers

K. Frank kfrank29.c at gmail.com
Thu Apr 10 16:58:38 CEST 2014


Hi Roland!

Just one quick comment, below:

On Thu, Apr 10, 2014 at 3:42 AM, Roland Winklmeier
<roland.m.winklmeier at gmail.com> wrote:
> Hi list,
>
> for my project I have to use a very old library.
> ...
> The question is now, which Thread API is best to use.
> ...
> and the most critical part
> - direct function calls synchronized via Mutexes from main thread
> ...
> - There are some methods I still have to call from the main thread, because
> I cannot really connect them via queued signal/slots. E.g. getIP() const or
> getKnownServers() const. So I still need to call it from a place in the main
> thread to get data out of the object:
> QString ip = networkWorker->getIP();
> Is this still safe to use (of course getIP() is synchronized via a mutex) or
> are there any other cleaner solutions?
> ...
> PS: the library sometimes blocks, so this is another reason why I want to
> have it in its own thread. But this is just a side note

Given that your main thread will be making mutex-protected calls
into your NetworkWorker object, the fact that the library blocks
could, depending on the details of your code, cause your main thread
to block.

Specifically, if your worker thread (that processes most of NetworkWorker's
logic) is holding one of the mutexes used to synchronized, e.g., getIP()
when it blocks, and then your main thread calls, e.g., getIP() (where I
assume that the code for getIP() itself acquires the relevant mutex, rather
than placing that responsibility on the client code), your main thread will
block until the library unblocks, letting the worker thread release the
mutex.

Again, this could only be a problem if the logic of your code is such that
NetworkWorker (or, more precisely, the logic of NetworkWorker that is
processed by the worker thread) could be holding the mutex when
NetworkWorker makes blocking calls into the library.

So if you can arrange it so that potentially blocking calls into the library
are only made when no mutexes are held, this particular problem won't
arise.

> ...
> Thanks for your help
>
> Regards Roland


Good luck.


K. Frank



More information about the Interest mailing list