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

來源:互聯網
上載者:User

我在《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); 對應的記憶體資料結構。

相關文章

E-Commerce Solutions

Leverage the same tools powering the Alibaba Ecosystem

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。