python - 扩展 Python 列表(例如 l += [1])是否保证是线程安全的？

Question

如果我有一个整数 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

Answer 1

对此没有满意的 ;-) 答案。没有任何保证，您可以通过注意 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!