muduo庫學習之線程同步03——不要用讀寫鎖和信号量

東陽的學習筆記

文章目錄

• • 不要使用讀寫鎖
  • 不要使用信号量

不要使用讀寫鎖

讀寫鎖并不像它看上去那樣那麼美妙！

1. 從正确性方面來說，一種典型的易犯錯誤是在持有

   read lock

   的時候

   修改了共享資料

   。這通常發生在程式的維護階段。程式員不小心在原來read lock保護的函數中調用了會修改狀态的函數
2. 從性能方面來說，讀寫鎖不見得比普通的 mutex_ 更高效。因為它要更新 reader 的數目。如果臨界區很小，鎖競争不激烈，那麼 mutex 往往會更快。

在多線程程式設計中我們總是設法縮短臨界區

1. reader lock 可能允許提升為 writer lock，也可能不允許提升。這會帶來移植性方面的問題。
2. 通常 reader lock 是可重入的，writer lock是不可重入的。但是為了防止 writer 饑餓，writer lock通常會阻塞後來的 reader lock，是以 reader lock 在重入時可能導緻死鎖。是以，追求

   低延遲讀取的場合也不适合使用讀寫鎖

作者語：muduo線程庫有意不提供讀寫鎖的封裝，因為我還沒有在工作中遇到過需要使用 rwlock 替代普通的 mutex_ 會顯著提高性能的例子。相反，我們建議首選 mutex。

不要使用信号量

作者語：我還沒有遇到過需要使用信号量的情況，無從談及個人經驗。我認為信号量不是必備的同步原語，是以條件變量配合互斥器可以完全替代其功能，而且更不易用錯。除了[RWC]指出 的“semaphore has no notion of ownership”之外，信号量的另一個問題在 于它有自己的計數值，而通常我們自己的資料結構也有長度值，這就造 成了同樣的資訊存了兩份，需要時刻保持一緻，這增加了程式員的負擔 和出錯的可能。如果要控制并發度，可以考慮用muduo::ThreadPool。