- 问题:这份代码在 3.11.3 中它居然输出 0 ,一度以为自己写错了,抱着不信邪的态度,又搞了个 Python 3.9.7 的环境试了下,果然还是符合自己预期,输出不为 0,想问下 3.11 版本中是做了什么修改吗?
python
import threading
num = 0
def add():
global num
for i in range(10_000_000):
num += 1
def sub():
global num
for i in range(10_000_000):
num -= 1
if __name__ == "__main__":
add_t = threading.Thread(target=add)
sub_t = threading.Thread(target=sub)
add_t.start()
sub_t.start()
add_t.join()
sub_t.join()
print("num result : %s" % num)
- 答案:
-
首先在 Python 字节码执行的时候 ,GIL 并不是随时能在任意位置中断切换线程。只有在主动检测中断的地方才可能发生线程切换。这个是大前提
-
3.10 之前的版本中,INPLACE_ADD 这个 opcode 之后 GIL 会去主动监测中断,所以导致现成不安全。3.10 的代码中有一个提交,
https://github.com/python/cpython/commit/4958f5d69dd2bf86866c43491caf72f774ddec97
根据 T. Wouters 的 Twitter 描述
https://twitter.com/Yhg1s/status/1460935209059328000
这次提交修改了 INPLACE_ADD 之后主动监测中断的操作。使得 INPLACE_ADD 之后无论如何都不会发生线程切换,因此虽然是两个 opcode ,但是确实是线程安全。
-
因为字节码中+=的操作是两步 opcode 操作,且 INPLACE_ADD 之后 GIL 会主动监测中断,导致虽然加了,但是没有重新赋值,就切换到了别的线程上**。比如 A 线程 当前 num=100 。+=1 之后 101 但是买没来得及重新赋值给 num ,GIL 切换了线程,再 B 线程中 num 还是 100 ,-=之后就是 99 ,但是这个线程却赋值给了 num ,此时 num 就是 99 然后又且回了 A 线程**。结果线程将中断时候的 101 赋值给了 num 导致此时 num 变成了 101 就出现问题了
-
3.10 以后就不会出现这个问题了,因为 INPLACE_ADD 操作之后 GIL 不再会主动检测中断,意味着正常情况下执行完+=之后线程不会被切换,而是正确执行了赋值给 num 的操作
-