shared_ptr是線程安全的嗎？
[導(dǎo)讀]來(lái)源|https://blog.csdn.net/Solstice/article/details/8547547聲明|?本文為CSDN博主[陳碩]原創(chuàng)文章，如有侵權(quán)請(qǐng)聯(lián)系刪除最近看見(jiàn)交流群里小伙伴在討論這個(gè)問(wèn)題，自己也很感興趣，上網(wǎng)找到了陳碩大佬的這篇文章，分享給大家！以下是正...
來(lái)源 | https://blog.csdn.net/Solstice/article/details/8547547聲明 |?本文為CSDN博主[陳碩]原創(chuàng)文章，如有侵權(quán)請(qǐng)聯(lián)系刪除
一個(gè) shared_ptr 對(duì)象實(shí)體可被多個(gè)線程同時(shí)讀?。ㄎ臋n例1）；
兩個(gè) shared_ptr 對(duì)象實(shí)體可以被兩個(gè)線程同時(shí)寫入（例2），“析構(gòu)”算寫操作；
如果要從多個(gè)線程讀寫同一個(gè) shared_ptr 對(duì)象，那么需要加鎖（例3~5）。
請(qǐng)注意，以上是 shared_ptr 對(duì)象本身的線程安全級(jí)別，不是它管理的對(duì)象的線程安全級(jí)別。
后文（p.18）則介紹如何高效地加鎖解鎖。本文則具體分析一下為什么“因?yàn)?shared_ptr 有兩個(gè)數(shù)據(jù)成員，讀寫操作不能原子化”使得多線程讀寫同一個(gè) shared_ptr 對(duì)象需要加鎖。這個(gè)在我看來(lái)顯而易見(jiàn)的結(jié)論似乎也有人抱有疑問(wèn)，那將導(dǎo)致災(zāi)難性的后果，值得我寫這篇文章。本文以 boost::shared_ptr 為例，與 std::shared_ptr 可能略有區(qū)別。
shared_ptr 的數(shù)據(jù)結(jié)構(gòu)
shared_ptr 是引用計(jì)數(shù)型（reference counting）智能指針，幾乎所有的實(shí)現(xiàn)都采用在堆（heap）上放個(gè)計(jì)數(shù)值（count）的辦法（除此之外理論上還有用循環(huán)鏈表的辦法，不過(guò)沒(méi)有實(shí)例）。具體來(lái)說(shuō)，shared_ptr 包含兩個(gè)成員，一個(gè)是指向 Foo 的指針 ptr，另一個(gè)是 ref_count 指針（其類型不一定是原始指針，有可能是 class 類型，但不影響這里的討論），指向堆上的 ref_count 對(duì)象。ref_count 對(duì)象有多個(gè)成員，具體的數(shù)據(jù)結(jié)構(gòu)如圖 1 所示，其中 deleter 和 allocator 是可選的。
圖 1：shared_ptr 的數(shù)據(jù)結(jié)構(gòu)
為了簡(jiǎn)化并突出重點(diǎn)，后文只畫(huà)出 use_count 的值：
以上是 shared_ptr x(new Foo); 對(duì)應(yīng)的內(nèi)存數(shù)據(jù)結(jié)構(gòu)。
如果再執(zhí)行 shared_ptr y = x; 那么對(duì)應(yīng)的數(shù)據(jù)結(jié)構(gòu)如下。
但是 y=x 涉及兩個(gè)成員的復(fù)制，這兩步拷貝不會(huì)同時(shí)（原子）發(fā)生。
中間步驟 1，復(fù)制 ptr 指針：
中間步驟 2，復(fù)制 ref_count 指針，導(dǎo)致引用計(jì)數(shù)加 1：
步驟1和步驟2的先后順序跟實(shí)現(xiàn)相關(guān)（因此步驟 2 里沒(méi)有畫(huà)出 y.ptr 的指向），我見(jiàn)過(guò)的都是先1后2。
既然 y=x 有兩個(gè)步驟，如果沒(méi)有 mutex 保護(hù)，那么在多線程里就有 race condition。
多線程無(wú)保護(hù)讀寫 shared_ptr 可能出現(xiàn)的 race condition考慮一個(gè)簡(jiǎn)單的場(chǎng)景，有 3 個(gè) shared_ptr 對(duì)象 x、g、n：
shared_ptr g(new Foo); // 線程之間共享的 shared_ptr shared_ptr x; // 線程 A 的局部變量 shared_ptr n(new Foo); // 線程 B 的局部變量 一開(kāi)始，各安其事。
線程 A 執(zhí)行 x = g; （即 read g），以下完成了步驟 1，還沒(méi)來(lái)及執(zhí)行步驟 2。這時(shí)切換到了 B 線程。
同時(shí)編程 B 執(zhí)行 g = n; （即 write g），兩個(gè)步驟一起完成了。
先是步驟 1：
再是步驟 2：
這是 Foo1 對(duì)象已經(jīng)銷毀，x.ptr 成了空懸指針！
最后回到線程 A，完成步驟 2：
多線程無(wú)保護(hù)地讀寫 g，造成了“x 是空懸指針”的后果。這正是多線程讀寫同一個(gè) shared_ptr 必須加鎖的原因。
當(dāng)然，race condition 遠(yuǎn)不止這一種，其他線程交織（interweaving）有可能會(huì)造成其他錯(cuò)誤。
思考，假如 shared_ptr 的 operator= 實(shí)現(xiàn)是先復(fù)制 ref_count（步驟 2）再?gòu)?fù)制 ptr（步驟 1），會(huì)有哪些 race condition？
雜項(xiàng)
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 > 雖然可以編譯通過(guò)，但是其 hash_value 是 shared_ptr 隱式轉(zhuǎn)換為 bool 的結(jié)果。也就是說(shuō)，如果不自定義hash函數(shù)，那么 unordered_{set/map} 會(huì)退化為鏈表。https://svn.boost.org/trac/boost/ticket/5216
Boost 1.51 在 boost/functional/hash/extensions.hpp 中增加了有關(guān)重載，現(xiàn)在只要包含這個(gè)頭文件就能安全高效地使用 unordered_set 了。
這也是 muduo 的 examples/idleconnection 示例要自己定義 hash_value(const boost::shared_ptr
一個(gè) shared_ptr 對(duì)象實(shí)體可被多個(gè)線程同時(shí)讀?。ㄎ臋n例1）；
兩個(gè) shared_ptr 對(duì)象實(shí)體可以被兩個(gè)線程同時(shí)寫入（例2），“析構(gòu)”算寫操作；
如果要從多個(gè)線程讀寫同一個(gè) shared_ptr 對(duì)象，那么需要加鎖（例3~5）。
請(qǐng)注意，以上是 shared_ptr 對(duì)象本身的線程安全級(jí)別，不是它管理的對(duì)象的線程安全級(jí)別。
后文（p.18）則介紹如何高效地加鎖解鎖。本文則具體分析一下為什么“因?yàn)?shared_ptr 有兩個(gè)數(shù)據(jù)成員，讀寫操作不能原子化”使得多線程讀寫同一個(gè) shared_ptr 對(duì)象需要加鎖。這個(gè)在我看來(lái)顯而易見(jiàn)的結(jié)論似乎也有人抱有疑問(wèn)，那將導(dǎo)致災(zāi)難性的后果，值得我寫這篇文章。本文以 boost::shared_ptr 為例，與 std::shared_ptr 可能略有區(qū)別。
shared_ptr 的數(shù)據(jù)結(jié)構(gòu)
shared_ptr 是引用計(jì)數(shù)型（reference counting）智能指針，幾乎所有的實(shí)現(xiàn)都采用在堆（heap）上放個(gè)計(jì)數(shù)值（count）的辦法（除此之外理論上還有用循環(huán)鏈表的辦法，不過(guò)沒(méi)有實(shí)例）。具體來(lái)說(shuō)，shared_ptr
圖 1：shared_ptr 的數(shù)據(jù)結(jié)構(gòu)
為了簡(jiǎn)化并突出重點(diǎn)，后文只畫(huà)出 use_count 的值：
以上是 shared_ptr
如果再執(zhí)行 shared_ptr
但是 y=x 涉及兩個(gè)成員的復(fù)制，這兩步拷貝不會(huì)同時(shí)（原子）發(fā)生。
中間步驟 1，復(fù)制 ptr 指針：
中間步驟 2，復(fù)制 ref_count 指針，導(dǎo)致引用計(jì)數(shù)加 1：
步驟1和步驟2的先后順序跟實(shí)現(xiàn)相關(guān)（因此步驟 2 里沒(méi)有畫(huà)出 y.ptr 的指向），我見(jiàn)過(guò)的都是先1后2。
既然 y=x 有兩個(gè)步驟，如果沒(méi)有 mutex 保護(hù)，那么在多線程里就有 race condition。
多線程無(wú)保護(hù)讀寫 shared_ptr 可能出現(xiàn)的 race condition考慮一個(gè)簡(jiǎn)單的場(chǎng)景，有 3 個(gè) shared_ptr
shared_ptr
線程 A 執(zhí)行 x = g; （即 read g），以下完成了步驟 1，還沒(méi)來(lái)及執(zhí)行步驟 2。這時(shí)切換到了 B 線程。
同時(shí)編程 B 執(zhí)行 g = n; （即 write g），兩個(gè)步驟一起完成了。
先是步驟 1：
再是步驟 2：
這是 Foo1 對(duì)象已經(jīng)銷毀，x.ptr 成了空懸指針！
最后回到線程 A，完成步驟 2：
多線程無(wú)保護(hù)地讀寫 g，造成了“x 是空懸指針”的后果。這正是多線程讀寫同一個(gè) shared_ptr 必須加鎖的原因。
當(dāng)然，race condition 遠(yuǎn)不止這一種，其他線程交織（interweaving）有可能會(huì)造成其他錯(cuò)誤。
思考，假如 shared_ptr 的 operator= 實(shí)現(xiàn)是先復(fù)制 ref_count（步驟 2）再?gòu)?fù)制 ptr（步驟 1），會(huì)有哪些 race condition？
雜項(xiàng)
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)在只要包含這個(gè)頭文件就能安全高效地使用 unordered_set
這也是 muduo 的 examples/idleconnection 示例要自己定義 hash_value(const boost::shared_ptr
下載文檔
