- 问题:这份代码在 3.11.3 中它居然输出 0 ,一度以为自己写错了,抱着不信邪的态度,又搞了个 Python 3.9.7 的环境试了下,果然还是符合自己预期,输出不为 0,想问下 3.11 版本中是做了什么修改吗?
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 就出现问题了文章来源:https://www.toymoban.com/news/detail-698772.html
-
3.10 以后就不会出现这个问题了,因为 INPLACE_ADD 操作之后 GIL 不再会主动检测中断,意味着正常情况下执行完+=之后线程不会被切换,而是正确执行了赋值给 num 的操作文章来源地址https://www.toymoban.com/news/detail-698772.html
-
到了这里,关于Python 3.11 版本是对线程安全做了什么更改吗的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!