如果我有一个整数 i
,那么在多个线程上执行 i += 1
是不安全的:
>>> i = 0
>>> def increment_i():
... global i
... for j in range(1000): i += 1
...
>>> threads = [threading.Thread(target=increment_i) for j in range(10)]
>>> for thread in threads: thread.start()
...
>>> for thread in threads: thread.join()
...
>>> i
4858 # Not 10000
但是,如果我有一个列表 l
,那么在多个线程上执行 l += [1]
似乎是安全的:
>>> l = []
>>> def extend_l():
... global l
... for j in range(1000): l += [1]
...
>>> threads = [threading.Thread(target=extend_l) for j in range(10)]
>>> for thread in threads: thread.start()
...
>>> for thread in threads: thread.join()
...
>>> len(l)
10000
l += [1]
是否保证是线程安全的?如果是这样,这适用于所有 Python 实现还是仅适用于 CPython?
编辑: 似乎 l += [1]
是线程安全的,但 l = l + [1]
不是。 ..
>>> l = []
>>> def extend_l():
... global l
... for j in range(1000): l = l + [1]
...
>>> threads = [threading.Thread(target=extend_l) for j in range(10)]
>>> for thread in threads: thread.start()
...
>>> for thread in threads: thread.join()
...
>>> len(l)
3305 # Not 10000
最佳答案
对此没有满意的 ;-) 答案。没有任何保证,您可以通过注意 Python 引用手册不保证原子性来确认这一点。
在 CPython 中,这是一个语用学问题。正如 effbot 文章的一部分所说,
In theory, this means an exact accounting requires an exact understanding of the PVM [Python Virtual Machine] bytecode implementation.
这就是事实。 CPython 专家知道 L += [x]
是原子的,因为他们知道以下所有内容:
+=
编译为INPLACE_ADD
字节码。- 列表对象的
INPLACE_ADD
的实现完全用C编写(执行路径上没有Python代码,所以GIL不能在字节码之间释放) . - 在
listobject.c
中,INPLACE_ADD
的实现是函数list_inplace_concat()
,在其执行过程中不需要执行任何用户Python代码(如果有,GIL 可能会再次发布)。
这听起来很难保持直截了当,但对于具有 effbot 了解 CPython 内部知识的人(在他撰写那篇文章时),确实不是。事实上,鉴于知识的深度,这一切都很明显;-)
因此,就语用学而言,CPython 专家一直自由地依赖于“‘看起来很原子’的操作实际上应该是原子的”,这也指导了一些语言决策。例如,effbot 列表中缺少的操作(在他写完那篇文章后添加到语言中):
x = D.pop(y) # or ...
x = D.pop(y, default)
支持添加 dict.pop()
的一个论点(当时)恰恰是明显的 C 实现将是原子的,而正在使用的(当时)替代方案:
x = D[y]
del D[y]
不是原子的(检索和删除是通过不同的字节码完成的,因此线程可以在它们之间切换)。
但是文档从来没有说 .pop()
是原子的,而且永远不会。这是一种“同意成年人”的事情:如果你足够熟练,可以有意识地利用这一点,你就不需要牵手了。如果你不够专业,那么 effbot 文章的最后一句话适用:
When in doubt, use a mutex!
出于务实的需要,核心开发人员永远不会破坏 effbot 示例(或 D.pop()
或 D.setdefault()
)的原子性CPython。不过,其他实现完全没有义务模仿这些务实的选择。实际上,由于在这些情况下的原子性依赖于 CPython 的特定形式的字节码以及 CPython 使用只能在字节码之间释放的全局解释器锁,因此 其他实现模仿它们可能是一个真正的痛苦.
而且你永远不会知道:某些 future 版本的 CPython 也可能会移除 GIL!我对此表示怀疑,但理论上这是可能的。但如果发生这种情况,我敢打赌,保留 GIL 的并行版本也会保留,因为大量代码(尤其是用 C
编写的扩展模块)也依赖 GIL 来确保线程安全。
值得重复:
When in doubt, use a mutex!
关于python - 扩展 Python 列表(例如 l += [1])是否保证是线程安全的?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/38266186/