[Qt-interest] QMutex deadlock without using QMutex

[Andre Somers]

On 27-4-2010 18:54, Gabriel M. Beddingfield wrote:
>
>
> On Tue, 27 Apr 2010, Andre Somers wrote:
>
>>> Perhaps switch from Qt::QueuedConnection to
>>> Qt::BlockingQueuedConnection (or the reverse).  You might get lucky.
>> Ehh? Swithing to a blocking connection would defeat the purpose of using
> [snip]
>> think... Or do I totally misunderstand the documentation here? If I try
>> it, I get up to about 25% CPU usage on my quad core system. That's
>> single threaded performance.
>
> But it didn't deadlock, right?
>
> Ok, scratch that one.  :-)
It took so long to process, that I finally cancelled it :-) But no, 
before that, no deadlocks.

> You said that the worker threads signal the coordinator thread.  In 
> response to this signal, the coordinator thread signals the workers.  
> Right?
Yes. When a worker signals the coordinator, the coordinator, after some 
other work, signals the worker(s) that are currently not bussy to start 
processing a new work package, as long as there is still work to be done.

> What happens when the workers respond faster than the coordinator 
> thread expects?  I.e. while it's still processing the signal from the 
> worker thread (and is dispatching the next workloa)d... it gets 
> another signal from the same worker thread.
Good question. I'm not a 100% sure. What I *expect* to happen, is the 
same that happens with any event in Qt: that that signal is not 
delivered untill the coordinator thread has returned to the eventloop. 
That would mean that the coordinator thread is in a consistent state at 
all times, since the work it is doing can not be interupted. Since the 
signals are queued, they are marchalled through the eventloop, right? 
That's the reason I opted to use queued connections in the first place.

André