多線程讀寫 shared_ptr需要加鎖的原因

我在《Linux 多線程服務端編程：使用 muduo C++ 網路程式庫》第 1.9 節“再論 shared_ptr 的線程 安全”中寫道：

（shared_ptr）的引用計數本身是安全且無鎖的，但對象的讀寫則不是，因為 shared_ptr 有兩個資料成員，讀寫操作不能原子化。根據文檔 （http://www.boost.org/doc/libs/release/libs/smart_ptr/shared_ptr.htm#ThreadSafety）， shared_ptr 的安全執行緒層級和內建類型、標準庫容器、std::string 一樣，即：

一個 shared_ptr 對象實體可被多個線程同時讀取（文檔例1）；

兩個 shared_ptr 對象實體可以 被兩個線程同時寫入（例2），“析構”算寫操作；

如果要從多個線程讀寫同一個 shared_ptr 對象，那麼需要加鎖（例3~5）。

請注意，以上是 shared_ptr 對象本身的線程安 全層級，不是它管理的對象的安全執行緒層級。

後文（p.18）則介紹如何高效地加鎖解鎖。本文 則具體分析一下為什麼“因為 shared_ptr 有兩個資料成員，讀寫操作不能原子化”使得多線程讀寫同 一個 shared_ptr 對象需要加鎖。這個在我看來顯而易見的結論似乎也有人抱有疑問，那將導致災難性 的後果，值得我寫這篇文章。本文以 boost::shared_ptr 為例，與 std::shared_ptr 可能略有區別。

shared_ptr 的資料結構

shared_ptr 是引用計數型（reference counting）智能指標 ，幾乎所有的實現都採用在堆（heap）上放個計數值（count）的辦法（除此之外理論上還有用迴圈鏈 表的辦法，不過沒有執行個體）。具體來說，shared_ptr<Foo> 包含兩個成員，一個是指向 Foo 的 指標 ptr，另一個是 ref_count 指標（其類型不一定是原始指標，有可能是 class 類型，但不影響這 裡的討論），指向堆上的 ref_count 對象。ref_count 對象有多個成員，具體的資料結構如圖 1 所示 ，其中 deleter 和 allocator 是可選的。

圖 1：shared_ptr 的數 據結構。

為了簡化並突出重點，後文只畫出 use_count 的值：

以上是 shared_ptr<Foo> x(new Foo); 對應的記憶體資料結構。