shared_ptr 是線程安全的嗎?
↓推薦關(guān)注↓
一個 shared_ptr 對象實體可被多個線程同時讀?。ㄎ臋n例1);
兩個 shared_ptr 對象實體可以被兩個線程同時寫入(例2),“析構(gòu)”算寫操作;
如果要從多個線程讀寫同一個 shared_ptr 對象,那么需要加鎖(例3~5)。
請注意,以上是 shared_ptr 對象本身的線程安全級別,不是它管理的對象的線程安全級別。
后文(p.18)則介紹如何高效地加鎖解鎖。本文則具體分析一下為什么“因為 shared_ptr 有兩個數(shù)據(jù)成員,讀寫操作不能原子化”使得多線程讀寫同一個 shared_ptr 對象需要加鎖。這個在我看來顯而易見的結(jié)論似乎也有人抱有疑問,那將導(dǎo)致災(zāi)難性的后果,值得我寫這篇文章。本文以 boost::shared_ptr 為例,與 std::shared_ptr 可能略有區(qū)別。
shared_ptr 的數(shù)據(jù)結(jié)構(gòu)
shared_ptr 是引用計數(shù)型(reference counting)智能指針,幾乎所有的實現(xiàn)都采用在堆(heap)上放個計數(shù)值(count)的辦法(除此之外理論上還有用循環(huán)鏈表的辦法,不過沒有實例)。具體來說,shared_ptr
圖 1:shared_ptr 的數(shù)據(jù)結(jié)構(gòu)
為了簡化并突出重點,后文只畫出 use_count 的值:
以上是 shared_ptr
如果再執(zhí)行 shared_ptr
但是 y=x 涉及兩個成員的復(fù)制,這兩步拷貝不會同時(原子)發(fā)生。
中間步驟 1,復(fù)制 ptr 指針:
中間步驟 2,復(fù)制 ref_count 指針,導(dǎo)致引用計數(shù)加 1:
步驟1和步驟2的先后順序跟實現(xiàn)相關(guān)(因此步驟 2 里沒有畫出 y.ptr 的指向),我見過的都是先1后2。
既然 y=x 有兩個步驟,如果沒有 mutex 保護,那么在多線程里就有 race condition。
多線程無保護讀寫 shared_ptr 可能出現(xiàn)的 race condition考慮一個簡單的場景,有 3 個 shared_ptr
shared_ptr
線程 A 執(zhí)行 x = g; (即 read g),以下完成了步驟 1,還沒來及執(zhí)行步驟 2。這時切換到了 B 線程。
同時編程 B 執(zhí)行 g = n; (即 write g),兩個步驟一起完成了。
先是步驟 1:
再是步驟 2:
這是 Foo1 對象已經(jīng)銷毀,x.ptr 成了空懸指針!
最后回到線程 A,完成步驟 2:
多線程無保護地讀寫 g,造成了“x 是空懸指針”的后果。這正是多線程讀寫同一個 shared_ptr 必須加鎖的原因。
當然,race condition 遠不止這一種,其他線程交織(interweaving)有可能會造成其他錯誤。
思考,假如 shared_ptr 的 operator= 實現(xiàn)是先復(fù)制 ref_count(步驟 2)再復(fù)制 ptr(步驟 1),會有哪些 race condition?
雜項
shared_ptr 作為 unordered_map 的 key
如果把 boost::shared_ptr 放到 unordered_set 中,或者用于 unordered_map 的 key,那么要小心 hash table 退化為鏈表。http://stackoverflow.com/questions/6404765/c-shared-ptr-as-unordered-sets-key/12122314#12122314
直到 Boost 1.47.0 發(fā)布之前,unordered_set
Boost 1.51 在 boost/functional/hash/extensions.hpp 中增加了有關(guān)重載,現(xiàn)在只要包含這個頭文件就能安全高效地使用 unordered_set
這也是 muduo 的 examples/idleconnection 示例要自己定義 hash_value(const boost::shared_ptr