讀寫問題是乙個經典的同步問題，主要針對保護很少更新的資料結構這種同步情況。
假設有乙個用於儲存dns條目快取的表，它用來將網域名稱解析為相應的ip位址。通常，乙個給定的dns條目將在很長一段時間裡保持不變——在許多情況下，dns條目會保持數年不變。雖然隨著使用者訪問不同的**，新的條目可能會被不時地新增到表中，但這一資料卻將在其真個生命中保持不變。定期檢查快取條目的有效性是很重要的，但是只是在細節已有實際改變的時候才會需要更新。
雖然更新是罕見的，但他們仍然會發生，並且如果這個快取可以從多個執行緒訪問，它就需要在更新過程中進行適當的保護，以確保所有執行緒在讀取快取時都不會看到損壞的資料結構。
我們知道使用std::mutex來保護資料結構就會顯得特別悲觀，因為這會在資料結構沒有進行修改時消除併發讀取資料結構的可能，因此我們需要另一種互斥元——讀寫鎖。讀寫鎖考慮到了兩個不同的用法：由單個寫執行緒獨佔訪問或共享，由多個讀執行緒併發訪問。
新的c++11標準庫並沒有直接提供這樣的互斥元，儘管已向標準委員會提議。由於這個建議未被接納，例子使用由boost庫提供的實現——boost::shared_mutex。對於更新操作，std::lock_guard和std::unique_lock可用於鎖定，以取代相應的std::mutex特化。這樣確保了獨佔訪問，就像std::mutex那樣。那些不需要更新資料結構的執行緒能夠轉而使用boost::shared_lock來獲得共享訪問。
#include
#include
#include
#include
class
dns_entry
;class
dns_cache
void
update_or_add_entry
(std::string const
& domain,
dns_entry const
& dns_details)
};
find_entry()使用乙個boost::shared_lock()例項來保護它，以供共享、唯讀的訪問；多個執行緒因而可以毫無問題的同時呼叫find_entry()。另一方面，update_or_add_entry()使用乙個std::lock_guard<>例項，在表被更新時提供獨佔訪問；不僅在呼叫update_or_add_entry()中其他執行緒被阻止進行更新，呼叫find_entry()的執行緒也會被阻塞。 多執行緒程式設計之讀寫鎖
多執行緒程式設計之讀寫鎖 pthread是 posix threads 的簡稱，是posix的執行緒標準。pthread讀寫鎖把對共享資源的訪問者分為讀者和寫者，讀者只對共享資源進行讀訪問，寫者只對共享資源進行寫操作。在互斥機制，讀者和寫者都需要獨立獨佔互斥量以獨佔共享資源，在讀寫鎖機制下，允許同時...
Linux多執行緒程式設計之讀寫鎖
讀寫鎖也是執行緒同步中的一種同步機制，簡單的來說 讀寫鎖既有讀的方面也有寫的方面，其中讀是共享鎖，而寫是獨佔鎖，而且系統中讀寫鎖的分配是寫鎖優先的。下面的用例，證明了讀鎖是共享鎖。thread fun1中加了讀鎖，但並沒有解讀鎖 thread fun2中也可以加讀鎖執行 如果thread fun2中...
多執行緒之讀寫鎖
之前沒真正使用讀寫鎖，看到別人對讀寫鎖的解釋總感覺一頭霧水。今天親自敲 實驗之後，才明了，原來如此。網上沒有一篇文章是能描述出自己理解的樣子，所以將自己的思路記下來。先提出疑問，邊自答邊找思路，有了思路，再回頭去執行一下 就清晰明了了。如果你急著想要一句話概括讀寫鎖，那我會告訴你 讀鎖是加在讀方法裡...