#include#include#include #include #include #include using namespace std;shared_ptr global_instance = make_shared(0);std::mutex g_i_mutex;void thread_fcn(){ //std::lock_guard<:mutex> lock(g_i_mutex); shared_ptr local = global_instance; // thread-safe for(int i = 0; i < 100000000; i++) { //*global_instance = *global_instance + 1; *local = *local + 1; }}//g++ -std=c++11 thead_01.cpp -lpthread int main(int argc, char** argv){ thread thread1(thread_fcn); thread thread2(thread_fcn); thread1.join(); thread2.join(); cout << "*global_instance is " << *global_instance << endl; return 0;}
思考10秒
执行结果:
预期结果:
*global_instance is 200000000
画外音:
执行结果 不是预期结果,肯定不是线程安全的。
为什么还说内置安全的。
shared_ptr
objects offer the same level of thread safety as built-in types
意思是说:
shared_ptr的引用计数本身是安全且无锁的。
多线程环境下,调用不同shared_ptr实例的成员函数是不需要额外的同步手段的
画外音
智能指针有2个成员,一个是引用计数是原子的,另外一个原始指针 不是
综合来说 就不是
继续查看文档shared_ptr_thread_safetyExamples: 引用计数改变 原子操作 安全
shared_ptr p(new int(42));
Code Example 4. Reading a shared_ptr
from two threads
// thread A
shared_ptr p2(p); // reads p
// thread B
shared_ptr p3(p); // OK, multiple reads are safe
Code Example 5. Writing different
shared_ptr
instances from two threads 引用计数改变 原子操作 安全
// thread A
p.reset(new int(1912)); // writes p
// thread B
p2.reset(); // OK, writes p2
Code Example 6. Reading and writing a
shared_ptr
from two threads
// thread A
p = p3; // reads p3, writes p
// thread B
p3.reset(); // writes p3; undefined, simultaneous read/write
Code Example 7. Reading and destroying a
shared_ptr
from two threads
// thread A
p3 = p2; // reads p2, writes p3
// thread B
// p2 goes out of scope: undefined, the destructor is considered a "write access"
Code Example 8. Writing a
shared_ptr
from two threads
// thread A
p3.reset(new int(1));
// thread B
p3.reset(new int(2)); // undefined, multiple writes
Starting with Boost release 1.33.0, shared_ptr
uses a lock-free implementation on most common platforms.
结论:多个线程同时读同一个shared_ptr对象是线程安全的,
但是如果是多个线程对同一个shared_ptr对象进行读和写,则需要加锁。
这里举个例子:怎么多线程调度执行顺序的不确定性。
为什么多线程读写 shared_ptr 要加锁?以下内容,摘自陈硕的 http://blog.csdn.net/solstice/article/details/8547547
1:shared_ptr 的数据结构
shared_ptr 是引用计数型(reference counting)智能指针,几乎所有的实现都采用在堆(heap)上放个计数值(count)的办法(除此之外理论上还有用循环链表的办法,不过没有实例)。
具体来说,shared_ptr 包含两个成员,一个是指向 Foo 的指针 ptr,另一个是 ref_count 指针(其类型不一定是原始指针,有可能是 class 类型,但不影响这里的讨论),指向堆上的 ref_count 对象。ref_count 对象有多个成员,具体的数据结构如图 1 所示,其中 deleter 和 allocator 是可选的。
图 1:shared_ptr 的数据结构。
为了简化并突出重点,后文只画出 use_count 的值:
以上是 shared_ptr x(new Foo); 对应的内存数据结构。
如果再执行 shared_ptr y = x; 那么对应的数据结构如下。
但是 y=x 涉及两个成员的复制,这两步拷贝不会同时(原子)发生。
中间步骤 1,复制 ptr 指针:
中间步骤 2,复制 ref_count 指针,导致引用计数加 1:
步骤1和步骤2的先后顺序跟实现相关(因此步骤 2 里没有画出 y.ptr 的指向),
我见过的都是先1后2。
既然 y=x 有两个步骤,如果没有 mutex 保护,那么在多线程里就有 race condition。
2:多线程无保护读写 shared_ptr 可能出现的 race condition
考虑一个简单的场景,有 3 个 shared_ptr 对象 x、g、n:
shared_ptr g(new Foo1); // 线程之间共享的 shared_ptrshared_ptr x; // 线程 A 的局部变量shared_ptr n(new Foo2); // 线程 B 的局部变量-------------------------------------------线程 Ax = g; (即 read g) //代码1 :赋值指针,赋值 引用计数-------------------------------------------线程 Bg = n;//代码2 :动作A 清空原来G指向Foo1, 动作B 然后重新赋值 Foo2测试场景:线程A 智能指针x 读取Foo1,然后还重置Foo1计数。线程 B: 销毁了Foo1线程A重置计数是,foo1已经被销毁。
一开始,各安其事:
变量 x 没有指向任何对象
线程 A 执行 x = g; (即 read g),以下完成了步骤 1,还没来及执行步骤 2。这时切换到了 B 线程。
x 开始赋值,其中2个成员 ,第一是原始指针 FOO1,第二个应用计数没来得及完成。
同时编程 B 执行 g = n; (即 write g),两个步骤一起完成了。
先是步骤 1:
再是步骤 2:
这时 Foo1 对象已经销毁,x.ptr 成了空悬指针!
FOO1 因为 全局对象g重置,开始销毁
最后回到线程 A,完成步骤 2:
多线程无保护地读写 g,造成了“x 是空悬指针”的后果。
最后线程A 开始使用 foo1 来 执行其他操作。其实已经被销毁了。不存在
这正是多线程读写同一个 shared_ptr 必须加锁的原因
查看代码https://www.boost.org/doc/libs/1_32_0/boost/detail/shared_count.hpptemplate<class T> class shared_ptr{ T * px; // contained pointer boost::detail::shared_count pn; // reference counter ,}class shared_count{private: sp_counted_base * pi_;}
思考与行动:
1。为什么用一个类来管理另外一个指针呢
提示:
聚合关系图:
组合关系图:
2. 共享指针缺点
提示: