[Qt-interest] QMutex deadlock without using QMutex

Gabriel M. Beddingfield gabrbedd at gmail.com
Tue Apr 27 18:10:40 CEST 2010



On Tue, 27 Apr 2010, Andre Somers wrote:

>> Shooting from the hip:  this sounds like a mistake.  You have a
>> multi-threaded, message-passing application, but you're ignoring the
>> fundamentals of multi-threaded, message-passing programming.
> Please enlighten me: which fundamentals are you refering to, exactly?

That you need to use a mutex (or some similar 
synchronization primative like a semaphore or atomic 
operation) when accessing/sharing data between threads. 
It sounded like you are saying, "I don't want to use mutexes 
for this application."

Anyway, just MHO...


> It was my understanding that by using a message passing system (such as
> Qt's Queued connections), the message passing system itself takes care
> of all synchronization needed. Note that my worker threads are only
> reading from shared resources, never writing to them. The workers keep a
> private storage with results, which are merged after all worker threads
> are done.

i.e. you're relying Qt's Queued Connections for thread 
synchronization primatives.  These, of course, are using 
Mutexes and Sempahores and Atomic ops.

> 0    QMutex::lock    qmutex.cpp    201    0x00e10f4e
> 1    QMutexLocker::relock    qmutex.h    120    0x00f5c564
> 2    QMutexLocker    qmutex.h    102    0x00f5c604
> 3    QCoreApplicationPrivate::sendPostedEvents
> qcoreapplication.cpp    1271    0x00efe127
> 4    qt_internal_proc    qeventdispatcher_win.cpp    482    0x00f1f73f
> 5    USER32!DefDlgProcW    C:\WINDOWS\syswow64\user32.dll    0
> 0x7d9472d8
> 6    ??        0    0x003f06a8
> 7    ??        0    0x00000401
> 8    ??        0    0x00000000
>
> Following the item at line 3, I notice that Qt is indeed using a mutex
> for the message passing. So, it seems we are dealing with Qt's mutex,
> not mine.
>
> Question is then: why does Qt's message system get into a deadlock?

Not sure.  Deadlocks are hard to solve.

In case you don't know, it usually happens when this is 
effectively executed:

     QMutex mut;

     void some_func()
     {
         mut.lock();
         //...
         mut.lock(); // <== deadlock
     }

The second lock() will wait for the mutex to unlock, which 
will never happen.

Perhaps switch from Qt::QueuedConnection to 
Qt::BlockingQueuedConnection (or the reverse).  You might 
get lucky.

-gabriel




More information about the Qt-interest-old mailing list