QMutex::lock() taken by same QThread several times consecutively

Question

I have a QThread spawned off from my main that is doing a synchronous read on a device. The read has a 1000ms timeout. The read is wrapped in a forever loop, and the read is protected with a QMutex. The basic code is:

Thread 1 - Read forever on a device

for (;;){
   readMutex.lock(); // Lock so that system cannot change device parameters in middle of read
   read (&devicePtr, 1000);
   readMutex.unlock; //Unlock so that thread 2 can grab lock if its waiting
}

I have another method that that runs under the main event loop that can set some parameters to the devicePointer. Its not safe to do that when the device is being read, so it tries to take the lock, then set the parameters, then unlock the mutex. This will allow the Thread 1 read loop to continue. The basic code is:

Thread 2 - Set device params

void setParm(){
   readMutex.lock();   //Expects to take lock as soon as Thread 1 unlocks it
   setParam (&devicePtr, PARAM);
   readMutex.unlock();   //Unlock so thread 1 can resume its read forever loop
}

I have some qDebug in the code dumping the thread id when each of the thread take the lock. What I see is that Thread 2 calls the lock and blocks while thread 1 has the lock and is doing the read. Thread 1 completes the read and unlocks the Mutex. Thread 1 moves on to the next iteration of the loop, and takes the lock again. Thread 2 remains blocked on the readMutex.lock () call. This will have 5 or 6 times before Thread 2 is eventually allowed to take the lock and proceed.

I have assumed that the QMutex queue up the threads with round robin, but it doesn't seem so with Thread 1 able to take the lock back on the next iteration. I can sort of force Thread 2 to take the lock if I add a QThread::msleep(250) to the end of Thread 1's loop after the unlock. That sleep does the trick, and Thread 2 is able to take the lock right away and set the device parameters.

Am I doing something wrong, is this a priority thing? Any idea how I can make this round robin through the threads without using a msleep to put Thread 1 in the background?

Answer 1

There is no way to ensure the scheduler will attend one or the other thread. You could try changing the priority of the running threads to give a better chance to execute to one over the other, but it will no warranty anything and not all system supports priority change (ie:linux does not).
You should use a QWaitCondition instead of the sleep (you could pass the sleep value as a timeout for that condition) and make each thread wakes one pending thread waiting on that condition (QWaitCondition::wakeOne) before waiting on it (QWaitCondition::wait).