QMutex stuck in locked state

Question

I have a function which is part of a class and in this function there is a mutex.lock at the beginning of the function and a mutex.unlock just before its return. Now I have encountered a situation where the mutex is stuck in the locked state. What could be doing this if this function is the only place where I use that mutex to lock and unlock. The function is called from the main thread and from 1 or 2 other QThreads.

UPDATE: the problem was due to the thread not sleeping in between function calls. Maybe the lack of a sleep relocked the mutex really fast? You could also call yieldCurrentThread();

if you've "fixed" this by inserting a sleep call, you have a deeper problem. — nos, Jan 23 '10 at 01:46
by the way QThread has a function called sleep. Why would adding a sleep mean there is a problem — yan bellavance, Jan 25 '10 at 17:02
I think that you original was closer to the truth. I'm seeing qthread step on the internal state of a qmutex created in a static member object. Does Qthread create qmutex objects from pool or something? — Joe Soul-bringer, May 26 '10 at 23:22

score 5 · Answer 1 · edited Dec 04 '16 at 04:47

5

If an exception is thrown in the function the unlock() at the end might not get executed. To make sure the QMutex gets unlocked in such cases you can do the locking with a QMutexLocker object. This object will automatically unlock the mutex when it get's destroyed, even if that happens during stack unwinding after an exception.

edited Dec 04 '16 at 04:47

Daniel Arnett

493
2
8
18

answered Jan 22 '10 at 23:19

sth

222,467
53
283
367

ok thanks I will add that and see if it never happens. Is there a way I can detect this unhandled exception? – yan bellavance Jan 22 '10 at 23:23
I'm having this problem too using QMutexLocker so I don't think this is it. – Joe Soul-bringer May 26 '10 at 23:23

score 1 · Answer 2 · answered Feb 23 '11 at 18:01

On Mac OS X I had QMutex hangs even in a 100% correct logic. I made a wrapper call around QMutex, which increased/decreased an atomic reference count, and QMutex was hanging at a place, where the reference count was signifying no held mutex.

This has happened to me once in Qt3, and once more in the recent Qt (4.6.2 or 4.7.0, I don't remember). Replacing QMutex with a custom class, that goes directly to OS primitives - solved the problem.

Note however, this problem only occurred on OS X in my case. On Windows the same code was working perfectly.

score 0 · Answer 3 · edited Feb 25 '18 at 10:31

0

My guess is that one of the other threads that calls this function is still holding the lock, and has not released it, so the next thread that tries to enter that section of code, has to wait until the lock is releasd.

Are there any blocking calls inside the lock/unlock code?

From the Qt QMutex Documentation:

When you call lock() in a thread, other threads that try to call lock() in the same place will block until the thread that got the lock calls unlock()

edited Feb 25 '18 at 10:31

ololuki

377
1
7
14

answered Jan 22 '10 at 23:15

Miguel Sevilla

466
3
11

1

actually if the thread keeps lock and unlocking the mutex there is a chance other threads wont have time to unlock it like my case: while(1){mutex.lock(); code-code-code; mutex.unlock();} – yan bellavance Jan 27 '10 at 03:05

score 0 · Accepted Answer · answered Jan 27 '10 at 02:58

0

The mutex was relocking right after unlocking from the same QThread so fast that the main thread didn't have time to lock it back. Adding a sleep or yieldCurrentThread() fixed the problem

answered Jan 27 '10 at 02:58

yan bellavance

4,710
20
62
93

QMutex stuck in locked state

4 Answers4