如果互斥锁变量是静态分配的，那么我们可以把它初始化成常值PTHREAD_MUTEX_INITIALIZER 例如 ：static pthread_mutex_t lock =PTHREAD_MUTEX_INITIALIZER; 如果互斥锁是动态分配的（例如malloc new）或者分配在共享内存区中，那么我们在运行之时通过调用pthread_mutex_init函数初始化它。
如果多个线程阻塞在等待同一个互斥锁上，那么该互斥锁解锁时，会唤醒优先级最高的被阻线程。读写锁信号量也是这样的。
互斥锁用于上锁，条件变量则用于等待。这两种不同类型的同步都是需要的。
条件变量的作用是在等待某个条件达成时自身要进行睡眠或阻塞，避免忙等待带来的不必要消耗，所以条件变量的作用在于同步。
个人感觉，使用条件变量的地方都完全可以用互斥锁去代替，效率问题而已。
虚假唤醒的正解是：
wikipedia中有关于spurious wakeups的大致描述：https://en.wikipedia.org/wiki/Spurious_wakeup。前半部分的描述不甚清楚。重点在于最后的一段话。
According to David R. Butenhof's Programming with POSIX Threads ISBN 0-201-63392-2:
"This means that when you wait on a condition variable,the wait may (occasionally) return when no thread specifically broadcast or signaled that condition variable.Spurious wakeups may sound strange, but on some multiprocessor systems, making condition wakeup completely predictable might substantially slow all condition variable operations. The race conditions that cause spurious wakeups should be considered rare."
其中提到，即使没有线程broadcast 或者signal条件变量，wait也可能偶尔返回。
注意：即使是虚假唤醒的情况，线程也是在成功锁住mutex后才能从condition_wait()中返回。即使存在多个线程被虚假唤醒，但是也只能是一个线程一个线程的顺序执行，也即：lock(mutex) 检查/处理 condition_wai()或者unlock(mutex)来解锁.
pthread_mutex_lock xxxxxxx pthread_cond_signal pthread_mutex_unlock
缺点：在某些线程的实现中，会造成等待线程从内核中唤醒（由于cond_signal)然后又回到内核空间（因为cond_wait返回后会发现锁并未解开的行为），所以一来一回会有性能的问题。但是在LinuxThreads或者NPTL里面，就不会有这个问题，因为在Linux 线程中，有两个队列，分别是cond_wait队列和mutex_lock队列， cond_signal只是让线程从cond_wait队列移到mutex_lock队列，而不用返回到用户空间，不会有性能的损耗。
所以在Linux中推荐使用这种模式。
之后的情况：
pthread_mutex_lock xxxxxxx pthread_mutex_unlock pthread_cond_signal
优点：不会出现之前说的那个潜在的性能损耗，因为在signal之前就已经释放锁了
缺点：如果unlock之后signal之前，发生进程交换，另一个进程（不是等待条件的进程）拿到这把梦寐以求的锁后加锁操作，那么等最终切换到等待条件的线程时锁被别人拿去还没归还，只能继续等待。而这在上面的放中间的模式下是不会出现的。
所以，在Linux下最好pthread_cond_signal放中间，但从编程规则上说，其他两种都可以。
原文：https://blog.csdn.net/zrf2112/article/details/52287915
原文：https://blog.csdn.net/y396397735/article/details/51778182
原文：https://blog.csdn.net/Tornado1102/article/details/76158390