Correct use of qwaitcondition

It is easy to use
QWaitCondition Synchronization for multithreading , One thread call QWaitCondition::wait() Block waiting , Until another thread calls QWaitCondition::wake() Wake up and continue to execute .

For the sake of description , It is assumed that the main thread calls Send() Send a packet to the communication port , Then block and wait for the packet to be returned before proceeding . Another thread （ Communication thread ） Continuously receive data from the communication port and parse it into packets , Then wake up the main thread . The following is the simplest method given online ：
 

//  Example 1 

//  The main thread 
Send(&packet);
mutex.lock();
condition.wait(&mutex); 
if (m_receivedPacket)
{
    HandlePacket(m_receivedPacket); //  Another thread sends packets back and forth 
}
mutex.unlock();


//  Communication thread 
m_receivedPacket = ParsePacket(buffer);  //  Parse the received data into packets 
condition.wakeAll();

Usually , The above code can run well . But in some special cases , There may be chaos , Greatly reduce the reliability of communication .

In the main thread , call Send(&packet) After sending , If the communication thread immediately receives the packet , It's too late to call in the main thread wait() When , Already first wakeAll() 了 , Obviously, this wake-up is invalid , But the main thread continues to call wait(), And then it's stuck there , Because the package that should be returned has been returned . After testing, the probability of this phenomenon is still very high , Because we can't guarantee that the main thread will always be scheduled first . Even if the main thread has called wait(), Nor can it guarantee the performance of the underlying operating system wait_block The system call precedes wake system call , After all wait() Functions are also encapsulated layer by layer .

Rigorous usage
QWaitCondition::wait() A locked QMutex object . It is necessary to . In the above example 1 code , Although we used mutex, But just for the sake of formality QMutex Parameters , Let the compiler compile normally , in fact , No other thread is used to this mutex. and mutex It is supposed to allow multiple threads to work in coordination , So the above example is for the main thread mutex It's invalid .

according to Qt manual ,wait() Function must pass in a locked mutex object , stay wait() In the process of execution ,mutex Always keep locked , Until the operating system is called wait_block At the moment of blocking mutex Unlock （ Strictly speaking, it should be atomic operation , That is, the system can ensure that it will unlock only when the blocking waiting instruction is actually executed ）. After another thread wakes up ,wait() The function will be given again at the first time mutex locked （ This operation is also atomic ）, Until the display calls mutex.unlock() Unlock .

It is also used in communication threads mutex after , The whole communication sequence is normal , The problem of example 1 is completely solved . The code is as follows ：

//  Example 2 

//  The main thread 
mutex.lock();
Send(&packet);
condition.wait(&mutex); 
if (m_receivedPacket)
{
    HandlePacket(m_receivedPacket); //  Another thread sends packets back and forth 
}
mutex.unlock();


//  Communication thread 
m_receivedPacket = ParsePacket(buffer);  //  Parse the received data into packets 
mutex.lock();
condition.wakeAll();
mutex.unlock();

In example 2 above , The main thread first mutex Lock occupied , That is, start from sending packets , Until QWaitCondition::wait() At the operating system level, the blocking wait instruction is really executed , During this period of time of the main thread ,mutex Always locked , Even if the communication thread soon receives the packet , Nor will it directly call wakeAll(), It's calling mutex.lock() Time blockage （ Because the main thread has mutex Occupy locked , Try locking again and you will be blocked ）, Until the main thread QWaitCondition::wait() Actually execute the blocking command of the operating system and release mutex, Communication thread mutex.lock() Just then there is a blockage , So let's keep going , call wakeAll(), At this point, the main thread must wake up successfully .

thus it can be seen , adopt mutex Protect the code with strict timing requirements , At the same time wakeAll() Also use the same mutex Protect it , This will guarantee ： There must be wait() , There's more wakeAll(), No matter what , Can guarantee this priority , Instead of putting an Oolong .

By extension
mutex and condition Joint use is a common design pattern in multithreading , Not only is Qt, about C++ Of std::condition_variable and std::mutex , as well as java Of synchronized / wait / notify It also applies to .
————————————————
Copyright notice ： This paper is about CSDN Blogger 「flyoxs」 The original article of , follow CC 4.0 BY-SA Copyright agreement , For reprint, please attach the original source link and this statement .
Link to the original text ：https://blog.csdn.net/flyoxs/article/details/54617342