-
Python 多线程为何要加锁
2020-07-07 17:26:16文章目录1. 全局解释器锁(GIL)2. 为何多线程访问内存要加锁 1. 全局解释器锁(GIL) CPython解释器在内存管理...由于存在GIL锁, 所以多线程应该是串行的, 但是为什么访问内存还需要加锁呢? CPython解释器为了模拟并发执1. 全局解释器锁(GIL)
- CPython解释器在内存管理上不是线程安全的, 所以创建出了一个GIL锁机制, 阻止多线程并行
- GIL锁只存在于CPython中, 对于JPython等就没有这个概念, 但由于JPython用的人比较少, 所以支持的模块也比较少, 最常用的还是CPython
2. 为何多线程访问内存要加锁
- 由于存在GIL锁, 所以多线程应该是串行的, 但是为什么访问内存还需要加锁呢?
- CPython解释器为了模拟并发执行, 默认会在线程执行100调CPU指令后(0.005s)尝试进行线程切换(修改切换时间, sys模块下sys.setswitchinterval()函数)
- 线程block后也会释放锁(例如线程执行I/O操作时)
-
为什么多线程读写 shared_ptr 要加锁?
2016-11-14 23:25:34为什么多线程读写 shared_ptr 要加锁陈硕(giantchen_AT_gmail_DOT_com)
2012-01-28
我在《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); 对应的内存数据结构。
如果再执行 shared_ptr<Foo> y = x; 那么对应的数据结构如下。
但是 y=x 涉及两个成员的复制,这两步拷贝不会同时(原子)发生。
中间步骤 1,复制 ptr 指针:
中间步骤 2,复制 ref_count 指针,导致引用计数加 1:
步骤1和步骤2的先后顺序跟实现相关(因此步骤 2 里没有画出 y.ptr 的指向),我见过的都是先1后2。
既然 y=x 有两个步骤,如果没有 mutex 保护,那么在多线程里就有 race condition。
多线程无保护读写 shared_ptr 可能出现的 race condition
考虑一个简单的场景,有 3 个 shared_ptr<Foo> 对象 x、g、n:
- shared_ptr<Foo> g(new Foo); // 线程之间共享的 shared_ptr
- shared_ptr<Foo> x; // 线程 A 的局部变量
- shared_ptr<Foo> n(new Foo); // 线程 B 的局部变量
一开始,各安其事。
线程 A 执行 x = g; (即 read g),以下完成了步骤 1,还没来及执行步骤 2。这时切换到了 B 线程。
同时编程 B 执行 g = n; (即 write G),两个步骤一起完成了。
先是步骤 1:
再是步骤 2:
这是 Foo1 对象已经销毁,x.ptr 成了空悬指针!
最后回到线程 A,完成步骤 2:
多线程无保护地读写 g,造成了“x 是空悬指针”的后果。这正是多线程读写同一个 shared_ptr 必须加锁的原因。
当然,race condition 远不止这一种,其他线程交织(interweaving)有可能会造成其他错误。
思考,假如 shared_ptr 的 operator= 实现是先复制 ref_count(步骤 2)再复制 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 发布之前,unordered_set<std::shared_ptr<T> > 虽然可以编译通过,但是其 hash_value 是 shared_ptr 隐式转换为 bool 的结果。也就是说,如果不自定义hash函数,那么 unordered_{set/map} 会退化为链表。https://svn.boost.org/trac/boost/ticket/5216
Boost 1.51 在 boost/functional/hash/extensions.hpp 中增加了有关重载,现在只要包含这个头文件就能安全高效地使用 unordered_set<std::shared_ptr> 了。
这也是 muduo 的 examples/idleconnection 示例要自己定义 hash_value(const boost::shared_ptr<T>& x) 函数的原因(书第 7.10.2 节,p.255)。因为 Debian 6 Squeeze、Ubuntu 10.04 LTS 里的 boost 版本都有这个 bug。
为什么图 1 中的 ref_count 也有指向 Foo 的指针?
shared_ptr<Foo> sp(new Foo) 在构造 sp 的时候捕获了 Foo 的析构行为。实际上 shared_ptr.ptr 和 ref_count.ptr 可以是不同的类型(只要它们之间存在隐式转换),这是 shared_ptr 的一大功能。分 3 点来说:
1. 无需虚析构;假设 Bar 是 Foo 的基类,但是 Bar 和 Foo 都没有虚析构。
shared_ptr<Foo> sp1(new Foo); // ref_count.ptr 的类型是 Foo*
shared_ptr<Bar> sp2 = sp1; // 可以赋值,自动向上转型(up-cast)
sp1.reset(); // 这时 Foo 对象的引用计数降为 1
此后 sp2 仍然能安全地管理 Foo 对象的生命期,并安全完整地释放 Foo,因为其 ref_count 记住了 Foo 的实际类型。
2. shared_ptr<void> 可以指向并安全地管理(析构或防止析构)任何对象;muduo::net::Channel class 的 tie() 函数就使用了这一特性,防止对象过早析构,见书 7.15.3 节。
shared_ptr<Foo> sp1(new Foo); // ref_count.ptr 的类型是 Foo*
shared_ptr<void> sp2 = sp1; // 可以赋值,Foo* 向 void* 自动转型
sp1.reset(); // 这时 Foo 对象的引用计数降为 1
此后 sp2 仍然能安全地管理 Foo 对象的生命期,并安全完整地释放 Foo,不会出现 delete void* 的情况,因为 delete 的是 ref_count.ptr,不是 sp2.ptr。
3. 多继承。假设 Bar 是 Foo 的多个基类之一,那么:
shared_ptr<Foo> sp1(new Foo);
shared_ptr<Bar> sp2 = sp1; // 这时 sp1.ptr 和 sp2.ptr 可能指向不同的地址,因为 Bar subobject 在 Foo object 中的 offset 可能不为0。
sp1.reset(); // 此时 Foo 对象的引用计数降为 1
但是 sp2 仍然能安全地管理 Foo 对象的生命期,并安全完整地释放 Foo,因为 delete 的不是 Bar*,而是原来的 Foo*。换句话说,sp2.ptr 和 ref_count.ptr 可能具有不同的值(当然它们的类型也不同)。
为什么要尽量使用 make_shared()?
为了节省一次内存分配,原来 shared_ptr<Foo> x(new Foo); 需要为 Foo 和 ref_count 各分配一次内存,现在用 make_shared() 的话,可以一次分配一块足够大的内存,供 Foo 和 ref_count 对象容身。数据结构是:
不过 Foo 的构造函数参数要传给 make_shared(),后者再传给 Foo::Foo(),这只有在 C++11 里通过 perfect forwarding 才能完美解决。
(.完.)
原文链接:http://www.cppblog.com/Solstice/archive/2013/01/28/197597.html
-
C++开发:为什么多线程读写shared_ptr要加锁的详细介绍
2020-09-05 11:09:45本篇文章介绍了,在C++中为什么多线程读写shared_ptr要加锁的详细说明。需要的朋友参考下 -
为什么多线程读写 shared_ptr 要加锁
2018-08-22 16:14:31我在《Linux 多线程服务端编程:使用 muduo C++ 网络库》第 1.9 节“再论 shared_ptr 的线程安全”中写道: (shared_ptr)的引用计数本身是安全且无锁的,但对象的读写则不是,因为 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 是可选的。下图是shared_ptr 的数据结构。为了简化并突出重点,后文只画出 use_count 的值:
以上是
shared_ptr<Foo> x(new Foo)
; 对应的内存数据结构。如果再执行
shared_ptr<Foo> y = x
; 那么对应的数据结构如下。但是 y=x 涉及两个成员的复制,这两步拷贝不会同时(原子)发生。
中间步骤 1,复制 ptr 指针:
中间步骤 2,复制 ref_count 指针,导致引用计数加 1:
步骤1和步骤2的先后顺序跟实现相关(因此步骤 2 里没有画出 y.ptr 的指向),我见过的都是先1后2。
既然 y=x 有两个步骤,如果没有 mutex 保护,那么在多线程里就有 race condition。
多线程无保护读写 shared_ptr 可能出现的 race condition
考虑一个简单的场景,有 3 个
shared_ptr<Foo>
对象 x、g、n:shared_ptr<Foo> g(new Foo)
; // 线程之间共享的 shared_ptrshared_ptr<Foo> x
; // 线程 A 的局部变量shared_ptr<Foo> n(new Foo)
; // 线程 B 的局部变量
一开始,各安其事。
线程 A 执行 x = g; (即 read g),以下完成了步骤 1,还没来及执行步骤 2。这时切换到了 B 线程。
同时编程 B 执行 g = n; (即 write g),两个步骤一起完成了。
先是步骤 1:
再是步骤 2:
这是 Foo1 对象已经销毁,x.ptr 成了空悬指针!
最后回到线程 A,完成步骤 2:
多线程无保护地读写 g,造成了“x 是空悬指针”的后果。这正是多线程读写同一个 shared_ptr 必须加锁的原因。
当然,race condition 远不止这一种,其他线程交织(interweaving)有可能会造成其他错误。
思考,假如 shared_ptr 的 operator= 实现是先复制 ref_count(步骤 2)再复制 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 发布之前,unordered_set
为什么图 1 中的 ref_count 也有指向 Foo 的指针?
shared_ptr<Foo> sp(new Foo)
在构造 sp 的时候捕获了 Foo 的析构行为。实际上 shared_ptr.ptr 和 ref_count.ptr 可以是不同的类型(只要它们之间存在隐式转换),这是 shared_ptr 的一大功能。分 3 点来说:1. 无需虚析构;假设 Bar 是 Foo 的基类,但是 Bar 和 Foo 都没有虚析构。
shared_ptr<Foo> sp1(new Foo)
; // ref_count.ptr 的类型是 Foo*shared_ptr<Bar> sp2 = sp1
; // 可以赋值,自动向上转型(up-cast)sp1.reset(); // 这时 Foo 对象的引用计数降为 1
此后 sp2 仍然能安全地管理 Foo 对象的生命期,并安全完整地释放 Foo,因为其 ref_count 记住了 Foo 的实际类型。
2.
shared_ptr<void>
可以指向并安全地管理(析构或防止析构)任何对象;muduo::net::Channel class 的 tie() 函数就使用了这一特性,防止对象过早析构,见书 7.15.3 节。shared_ptr<Foo> sp1(new Foo)
; // ref_count.ptr 的类型是 Foo*shared_ptr<void> sp2 = sp1
; // 可以赋值,Foo* 向 void* 自动转型sp1.reset(); // 这时 Foo 对象的引用计数降为 1
此后 sp2 仍然能安全地管理 Foo 对象的生命期,并安全完整地释放 Foo,不会出现 delete void* 的情况,因为 delete 的是 ref_count.ptr,不是 sp2.ptr。
3. 多继承。假设 Bar 是 Foo 的多个基类之一,那么:
shared_ptr<Foo> sp1(new Foo)
;shared_ptr<Bar> sp2 = sp1
; // 这时 sp1.ptr 和 sp2.ptr 可能指向不同的地址,因为 Bar subobject 在 Foo object 中的 offset 可能不为0。sp1.reset(); // 此时 Foo 对象的引用计数降为 1
但是 sp2 仍然能安全地管理 Foo 对象的生命期,并安全完整地释放 Foo,因为 delete 的不是 Bar*,而是原来的 Foo*。换句话说,sp2.ptr 和 ref_count.ptr 可能具有不同的值(当然它们的类型也不同)。
为什么要尽量使用 make_shared()?
为了节省一次内存分配,原来
shared_ptr<Foo> x(new Foo)
; 需要为 Foo 和 ref_count 各分配一次内存,现在用 make_shared() 的话,可以一次分配一块足够大的内存,供 Foo 和 ref_count 对象容身。数据结构是:不过 Foo 的构造函数参数要传给 make_shared(),后者再传给 Foo::Foo(),这只有在 C++11 里通过 perfect forwarding 才能完美解决。
此文章转载自:https://blog.csdn.net/solstice/article/details/8547547
-
为什么多线程读写shared_ptr要加锁?[转]
2017-08-15 02:17:41原文:为什么多线程读写 shared_ptr 要加锁?shared_ptr的引用计数本身是安全且无锁的,但对象的读写则不是,因为shared_ptr有两个数据成员,读写操作不能原子化。shared_ptr的线程安全级别和内建类型、标准库容器、...shared_ptr
的引用计数本身是安全且无锁的,但对象的读写则不是,因为shared_ptr
有两个数据成员,读写操作不能原子化。shared_ptr
的线程安全级别和内建类型、标准库容器、std::string
一样,即:- 一个
shared_ptr
对象实体可被多个线程同时读取 - 两个
shared_ptr
对象实体可以被两个线程同时写入 - 如果要从多个线程读写同一个
shared_ptr
对象,那么需要加锁
请注意,以上是
shared_ptr
对象本身的线程安全级别,不是它管理的对象的线程安全级别。shared_ptr
的数据结构shared_ptr
是引用计数型(reference counting)智能指针,几乎所有的实现都采用在堆(heap)上放个计数值(count)的办法(除此之外理论上还有用循环链表的办法,不过没有实例)。具体来说,shared_ptr<Foo>
包含两个成员,一个是指向Foo
的指针ptr
,另一个是ref_count
指针(其类型不一定是原始指针,有可能是class
类型,但不影响这里的讨论),指向堆上的ref_count
对象。ref_count
对象有多个成员,具体的数据结构如图所示,其中deleter
和allocator
是可选的。为了简化并突出重点,后文只画出
use_count
的值:以上是
shared_ptr<Foo> x(new Foo);
对应的内存数据结构。如果再执行
shared_ptr<Foo> y = x;
那么对应的数据结构如下:但是
y=x
涉及两个成员的复制,这两步拷贝不会同时(原子)发生。- 步骤1:复制
ptr
指针:
- 步骤2:复制
ref_count
指针,导致引用计数加1:
步骤1和步骤2的先后顺序跟实现相关(因此步骤2里没有画出
y.ptr
的指向),我见过的都是先1后2。既然
y=x
有两个步骤,如果没有mutex
保护,那么在多线程里就有race condition。多线程无保护读写
shared_ptr
可能出现的race condition考虑一个简单的场景,有3个
shared_ptr<Foo>
对象x,g,n
:shared_ptr<Foo> g(new Foo); // 线程之间共享的 shared_ptr shared_ptr<Foo> x; // 线程 A 的局部变量 shared_ptr<Foo> n(new Foo); // 线程 B 的局部变量
线程A执行
x = g;
(即read g),以下完成了步骤1,还没来及执行步骤2。这时切换到了B线程。同时线程B执行
g = n;
(即write g),两个步骤一起完成了。先是步骤1:
再是步骤2:
这是
Foo1
对象已经销毁,x.ptr
成了空悬指针!最后回到线程A,完成步骤2:
多线程无保护地读写
g
,造成了x
是空悬指针的后果。这正是多线程读写同一个shared_ptr
必须加锁的原因。当然,race condition远不止这一种,其他线程交织(interweaving)有可能会造成其他错误。
其他
1. 为什么
ref_count
也有指向Foo
的指针?shared_ptr<Foo> sp(new Foo)
在构造sp
的时候捕获了Foo
的析构行为。实际上shared_ptr.ptr
和ref_count.ptr
可以是不同的类型(只要它们之间存在隐式转换),这是shared_ptr
的一大功能。分3点来说:1)无需虚析构。假设
Bar
是Foo
的基类,但是Bar
和Foo
都没有虚析构。shared_ptr<Foo> sp1(new Foo); // ref_count.ptr的类型是Foo* shared_ptr<Bar> sp2 = sp1; // 可以赋值,自动向上转型(up-cast) sp1.reset(); // 这时Foo对象的引用计数降为1
此后
sp2
仍然能安全地管理Foo
对象的生命期,并安全完整地释放Foo
,因为其ref_count
记住了Foo
的实际类型。2)
shared_ptr<void>
可以指向并安全地管理(析构或防止析构)任何对象。shared_ptr<Foo> sp1(new Foo); // ref_count.ptr的类型是Foo* shared_ptr<void> sp2 = sp1; // 可以赋值,Foo*向void*自动转型 sp1.reset(); // 这时Foo对象的引用计数降为1
此后
sp2
仍然能安全地管理Foo
对象的生命期,并安全完整地释放Foo
,不会出现delete void*
的情况,因为delete
的是ref_count.ptr
,不是sp2.ptr
。3)多继承。假设
Bar
是Foo
的多个基类之一,那么:shared_ptr<Foo> sp1(new Foo); shared_ptr<Bar> sp2 = sp1; // 这时sp1.ptr和sp2.ptr可能指向不同的地址,因为Bar subobject在Foo object中的offset可能不为0。 sp1.reset(); // 此时Foo对象的引用计数降为1
但是
sp2
仍然能安全地管理Foo
对象的生命期,并安全完整地释放Foo
,因为delete
的不是Bar*
,而是原来的Foo*
。换句话说,sp2.ptr
和ref_count.ptr
可能具有不同的值(当然它们的类型也不同)。2. 为什么要尽量使用
make_shared()
?为了节省一次内存分配,原来
shared_ptr<Foo> x(new Foo);
需要为Foo
和ref_count
各分配一次内存,现在用make_shared()
的话,可以一次分配一块足够大的内存,供Foo
和ref_count
对象容身。数据结构是:不过
Foo
的构造函数参数要传给make_shared()
,后者再传给Foo::Foo()
,这只有在C++11里通过perfect forwarding才能完美解决。 - 一个
-
(java多线程)线程的同步(加锁)+Timer定时器
2020-03-13 16:09:05什么时候要同步,为什么要引入线程同步呢? 1.为了数据的安全。可以不考虑效率,因为同步机制加入后,效果等同同单线程的 2.什么条件下要使用线程同步? 第一:必须是多线程环境 第二:多线程环境共享同一个数据 第三... -
shared_ptr的线程安全性---为什么多线程读写 shared_ptr 要加锁?
2014-04-26 10:13:58为什么多线程读写 shared_ptr 要加锁?陈硕(giantchen_AT_gmail_DOT_com)2012-01-28最新版下载:http://chenshuo.googlecode.com/files/CppEngineering.pdf我在《Linux 多线程服务端编程:使用 muduo C++ 网络库》... -
双重检测加锁为什么要使用volitail_多线程学习笔记
2021-01-30 18:13:56多线程出现目的如何使用多线程线程状态(6种)线程开启/停止线程安全VolilateSychronized机制如何实现锁为什么任何一个对象都可以成为锁锁的优化Lock与Synchronized区别CASAQS(AbstractQueuedSychronizer)... -
读锁有什么用?读为什么要加锁?
2020-07-16 19:58:55读为什么要加锁? 1、有些同学认为读锁没有用,他们的理由是:读操作又不会修改数据,想读就读呗,无论读的是就值还是新值,反正能读到。 2、也有同学认为读锁是为了防止多线程读到的数据不一致。 我认为不是这个...
-
从 Notbook 到 JupyterLab, 再配上代码帮手 Kite
-
2021-02-25
-
【PHP】php 递归、效率和分析
-
龙芯实训平台应用实战(希云)
-
朱老师C++课程第3部分-3.6智能指针与STL查漏补缺
-
ELF视频教程
-
Markdown 标记语言
-
通过成形InGaN / GaN纳米棒来修改远场辐射图
-
龙芯生态应用开发基础:C语言精要
-
【Java并发编程】synchronized(一):生产者消费者问题
-
构建低成本高密度Wi-Fi网络实验床
-
百亿级日志系统架构设计及优化
-
自动化测试Python3+Selenium3+Unittest
-
聊聊分布式事务,再说说解决方案
-
leetcode算法第四题
-
FastDFS 分布式文件系统部署
-
程序员必修基础套餐课
-
SecureCRT 连接 GNS3/Linux 的安全精密工具
-
i++ 和 ++i 到底怎么分析?
-
Linux基础入门系列课程