[Qt-interest] QMutex deadlock without using QMutex

[Gabriel M. Beddingfield]

On Tue, 27 Apr 2010, André Somers wrote:

> set to be exact.) They are not called directly as you do above.

Yes.  But you gotta simplify your examples /somewhere/.  The 
point is that while one function is executing... another 
thread somewhere could steal your worker thread.  This is 
especially true since you're using asynchronous queues to 
pass the work.

> Would that not mean that just like for the coordinator thread, the worker
> threads are not interrupted, as the slot would only be invoked when the
> worker thread returns to the eventloop? Also: I don't see the deadlock in

Well, you can always set up a simple test to prove your 
assumption:

    #include <QMutex>
    #include <cassert>

    class WorkerThread
    {
        Q_OBJECT
    public slot:
        void do_work();

    signals:
        void some_signal();

    private:
        mutable QMutex _mutex; // locked while calculating
    };

    void WorkerThread::do_work()
    {
        if( _state_mutex.trylock() ) {
            // do calcs
            emit some_signal();
            _state_mutex.unlock();
        } else {
            assert(false);
        }
    }

The purpose here is to crash your program if somehow the 
do_work() method gets called twice at the same time. 
(Which, if I understand correctly, should not be 
happening.)  If this test fails... it can help you isolate 
the cause.

Note that /this/ mutex will not serialize (single-thread) 
your program like Qt::BlockingQueuedConnection did.

hth,
Gabriel