一、
QWaitCondition
不是通过 强制执行互斥，而是通过提供 条件变量 来同步线程。
1.1 使用 互斥量 和 QReadWriteLock，存在的一个问题
1.2 QWaitCondition+QMutex
1.3
1.4 消费者线程先启动
2个线程启动的先后顺序不应调换：用先启动threadConsumer，使其先进入wait状态。后启动threadProducer，
这样，在threadProducer里wakeAll()时，threadConsumer就可以及时响应。
否则，会丢失第一次掷骰子的数据。
执行顺序：
QThreadConsumer(mutex.lock())=>
QThreadConsumer(newdataAvailable.wait(&mutex))=>
QThreadProducer(mutex.lock())=>
QThreadProducer(mutex.unlock())=>
QThreadProducer(newdataAvailable.waitAll())=>
QThreadConsumer(emit newValue(seq,diceValue))=>
QThreadConsumer(mutex.unlock())
wait() 函数参数：必须传入一个已上锁的 mutex 对象；
1.5
//因为threadB可能处于等待状态，所以用terminate强制结束；
//生产者线程中没有wait函数，所以不可能处理等待状态！就不用terminate强制结束！
注：本例源于“Qt5.9 c++开发指南”中案例
二、原文：QWaitCondition 的正确使用方法-CSDN博客
1、简单用法
QWaitCondition 用于多线程的同步，一个线程调用QWaitCondition::wait() 阻塞等待，直到另一个线程调用QWaitCondition::wake() 唤醒才继续往下执行。
为了描述方便，这里假设主线程（非Qt的UI线程）调用Send()往通信口发送一个数据包，然后阻塞等待回包才继续往下执行。另一个线程（通信线程）不断从通信口中接收数据并解析成数据包，然后唤醒主线程。下面是按网上给的最简单的方法：
// 示例一
// 主线程
Send(&packet);
mutex.lock();
condition.wait(&mutex);
if (m_receivedPacket)
{
HandlePacket(m_receivedPacket); // 另一线程传来回包
}
mutex.unlock();
// 通信线程
m_receivedPacket = ParsePacket(buffer); // 将接收的数据解析成包
condition.wakeAll();
通常情况下，上述代码能跑得很好。但在某些特殊情况下，可能会出现混乱，大大降低通信可靠性。
在主线程中，调用 Send(&packet) 发送后，假如通信线程立即收到回包，在主线程还来不及调用 wait() 的时候，已经先 wakeAll() 了，显然这次唤醒是无效的，但主线程继续调用 wait()，然后一直阻塞在那里，因为该回的包已经回了。经测试出现这种现象的概率还是挺大的，因为我们不敢保证主线程总会被优先调度。即使主线程已经调用了 wait()，也不能保证底层操作系统的 wait_block 系统调用先于 wake 系统调用，毕竟wait() 函数也是层层封装的。
2、严谨用法
QWaitCondition::wait() 在使用时必须传入一个上锁的 QMutex 对象。这是很有必要的。而上述示例一代码中，我们虽然用了 mutex，但只是为了形式上传入QMutex参数，让编译器能正常编译而已，事实上，没有其它任何线程再用到这个mutex。而 mutex 本来就是让多个线程能协调工作的，所以上述示例一主线程用的 mutex 是无效的。
根据 Qt 手册（见下节内容），wait() 函数必须传入一个已上锁的 mutex 对象，在 wait() 执行过程中，mutex一直保持上锁状态，直到调用操作系统的wait_block 在阻塞的一瞬间把 mutex 解锁（严格说来应该是原子操作，即系统能保证在真正执行阻塞等待指令时才解锁）。另一线程唤醒后，wait() 函数将在第一时间重新给 mutex 上锁（这种操作也是原子的），直到显示调用 mutex.unlock() 解锁。
在通信线程也用上 mutex 后，整个通信时序正常了，完全解决了示例一的问题。代码如下：
// 示例二
// 主线程
mutex.lock();
Send(&packet);
condition.wait(&mutex);
if (m_receivedPacket)
{
HandlePacket(m_receivedPacket); // 另一线程传来回包
}
mutex.unlock();
// 通信线程
m_receivedPacket = ParsePacket(buffer); // 将接收的数据解析成包
mutex.lock();
condition.wakeAll();
mutex.unlock();
上述示例二中，主线程先把 mutex 锁占据，即从发送数据包开始，一直到 QWaitCondition::wait() 在操作系统层次真正执行阻塞等待指令，这一段主线程的时间段内，mutex 一直被上锁，即使通信线程很快就接收到数据包，也不会直接调用 wakeAll()，而是在调用 mutex.lock() 时阻塞住（因为主线程已经把mutex占据上锁了，再尝试上锁就会被阻塞），直到主线程 QWaitCondition::wait() 真正执行操作系统的阻塞等待指令并释放mutex，通信线程的 mutex.lock() 才即出阻塞，继续往下执行，调用 wakeAll()，此时一定能唤醒主线程成功。
由此可见，通过 mutex 把有严格时序要求的代码保护起来，同时把 wakeAll() 也用同一个 mutex 保护起来，这样能保证：一定先有 wait() ，再有 wakeAll()，不管什么情况，都能保证这种先后关系。
