muduo库学习之线程同步03——不要用读写锁和信号量

东阳的学习笔记

不要使用读写锁

读写锁并不像它看上去那样那么美妙！

1. 从正确性方面来说，一种典型的易犯错误是在持有 read lock 的时候修改了共享数据。这通常发生在程序的维护阶段。程序员不小心在原来read lock保护的函数中调用了会修改状态的函数
2. 从性能方面来说，读写锁不见得比普通的 mutex_ 更高效。因为它要更新 reader 的数目。如果临界区很小，锁竞争不激烈，那么 mutex 往往会更快。

在多线程编程中我们总是设法缩短临界区

3. reader lock 可能允许提升为 writer lock，也可能不允许提升。这会带来移植性方面的问题。
4. 通常 reader lock 是可重入的，writer lock是不可重入的。但是为了防止 writer 饥饿，writer lock通常会阻塞后来的 reader lock，因此 reader lock 在重入时可能导致死锁。因此，追求低延迟读取的场合也不适合使用读写锁

作者语：muduo线程库有意不提供读写锁的封装，因为我还没有在工作中遇到过需要使用 rwlock 替代普通的 mutex_ 会显著提高性能的例子。相反，我们建议首选 mutex。

不要使用信号量

作者语：我还没有遇到过需要使用信号量的情况，无从谈及个人经验。我认为信号量不是必备的同步原语，因此条件变量配合互斥器可以完全替代其功能，而且更不易用错。除了[RWC]指出 的“semaphore has no notion of ownership”之外，信号量的另一个问题在 于它有自己的计数值，而通常我们自己的数据结构也有长度值，这就造 成了同样的信息存了两份，需要时刻保持一致，这增加了程序员的负担 和出错的可能。如果要控制并发度，可以考虑用muduo::ThreadPool。