[Qt-interest] Is it "bad" to call a blocking function of Thread B directly in Thread A?

[Sven Grunewaldt]

Thank you both for your answers! I was really confused about threads and
how they _really_ work. After reading your mails I talked to a colleague
and he also explained me how threads and methods work in the "background".

I guess I do understand now where the problems lie in concurrent
execution and what "thread-safety" means.

Since this is a really small project just for me and the mentioned
colleague I think I'll stick to the direct calling of the method and
clean out the threading mess I've produced by using only one thread for
the Consumer instance.

Thanks for pointing me in the right direction!

Regards,
Sven Grunewaldt

Am 06.10.2010 16:10, schrieb K. Frank:
> Hi Sven -
> 
> On Wed, Oct 6, 2010 at 7:33 AM, Sven Grunewaldt <strayer at olle-orks.org> wrote:
>> Hi,
>>
>> let's assume I have two classes, Producer and Consumer. Both of these
>> classes run in their own QThread. Now I want to call a blocking function
>> of Producer within Consumer (via a pointer to the instance).
> 
> First, to be precise, we should distinguish between a thread of execution and
> an instance of a QThread object.  The two are connected in that a QThread
> object manages a thread of execution, and a QThread object has (as do all
> QObjects) "affinity" for a thread of execution, and this affinity
> determines which
> thread executes the QThread's slots.
> 
> A big source of confusion is that the thread of execution managed by a QThread
> and the thread of execution for which the QThread has affinity are not
> necessarily
> the same, and, in fact, are usually different.
> 
> I assume that you mean that you "have two [instances of] classes, Producer
> and Consumer" that are QThread objects, i.e., derived from QThread
> 
> AND
> 
> that the bulk of the processing done by each of these instances is carried out
> in the thread of execution managed by the instance in question.
> 
>> There is no possibility of two Consumers trying to access the same
>> Producer at the same time and stuff like that. Only one Consumer and one
>> Producer.
>>
>> I tried this with a simple testcase and it seems to work:
>> http://pastebin.ca/1955512 (Sorry for the Windows.h and Sleep() )
>>
>> I think I could achieve the same thing with Signals/Slots and
>> QWaitCondition, but since there are only two instances and no real
>> concurrence this looks way to complicated.
>>
>> Is this in some way dangerous, very bad practice, not portable, etc.?
> 
> It is not "bad" to call a member function of a QThread object from
> either a thread
> of execution that is not managed by the QThread or from a thread of execution
> for which the QThread does not have affinity.
> 
> After all, member function are just functions, and functions get
> called by whichever
> threads of execution decide to call them.
> 
> Technically, this is just fine.
> 
> There are some caveats:
> 
> You might consider it bad style (I don't) if your project team isn't
> expecting this
> "cross-thread function calling" and finds it confusing or if it is
> proscribed by your
> coding standards.
> 
> If the function might be called by more than on thread at the same
> time, it needs
> to be thread-safe, just like any function.
> 
> If the function emits a signal, the signal is emitted by the calling thread (and
> neither by the thread managed by the QThread nor by the thread for which the
> QThread has affinity).  There's nothing wrong with this, but it may
> cause confusion
> if you don't bear this in mind when analyzing which thread of
> execution will execute
> the receiving slot.
> 
> Good luck.
> 
> 
> K. Frank
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest