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

[Arnold Krille]

On Wednesday 06 October 2010 13:33:32 Sven Grunewaldt wrote:
> 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).
> 
> 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.?

The function is executed in the thread where its called. It doesn't matter if 
the producer lives in another thread, when the consumer in thread b calls a 
function of the producer, this function is running in thread b.

As you call Producer::produce() from within the second thread, its executed 
there. In your example there is no reason to have the producer in its own 
thread...

The real solution for a producer-consumer thing is to run(!) the objects in 
their own threads with some kind of event-loop or sleep-loop. The producer 
produces when its told so (by some variable of toproduce) and sends that data 
to the consumer, the consumer reads this data and does its consuming thing.
To de-couple the two, there are several ways:
 1. Have an output-queue in the producer. The producer appends its products 
there, the consumer regularly checks whether the queue is not-empty and 
consumes.
 2. Have an input-queue at the consumer.
 3. Make the producer send its products via signal. Connect that signal to a 
slot in the consumer.

1. and 2. have a rather tight coupling of producer and consumer as one of them  
has to know the others address or at least the address of the queue.
3. is the more qt-way loose coupling as qt's event-system does all the 
queuing. Yes, the event-system does the job here as sender and receiver live 
in different threads, therefor the connection becomes an event. When you send 
data over this connection, you can either send pointers (which becomes a 
hazzle when you need to keep track to delete them) or send data-types (the 
QShared* stuff will help you there with the ref-counting and the shallow-
copies).

Have fun,

Arnold
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20101006/3bbe1b70/attachment.bin