sw_interval = sys.getswitchinterval()
try:
# Setting the switch interval to a very big number to make sure that their will be no
# thread context switching while running the operations that came after.
sys.setswitchinterval(sys.maxint)
# Expressions run here will be atomic ....
finally:
sys.setswitchinterval(sw_interval)
另一种用途是在您面临 护航效应（或新 GIL 性能不佳的任何边缘情况）。也许（只是也许）改变上下文切换间隔可以给你带来更快的速度。
免责声明：上面引用的第一种方法被认为是黑魔法，完全不推荐使用（在该用例中，类似 threading.Lock 的方法是首选）。一般来说，我不认为在正常情况下改变线程上下文切换间隔是应该做的事情。我将解释 Tim Peters 已经说过的关于元类的话：更改线程上下文切换间隔比 99% 的人需要的更深的魔力。
One use will be to make sure that operation(s) run atomically, for example:
sw_interval = sys.getswitchinterval()
try:
# Setting the switch interval to a very big number to make sure that their will be no
# thread context switching while running the operations that came after.
sys.setswitchinterval(sys.maxint)
# Expressions run here will be atomic ....
finally:
sys.setswitchinterval(sw_interval)
Another use case will be to tune your code specially when you're facing the convoy effect (or any edge case where the new GIL give bad performance). Maybe (just maybe) changing the context switch interval can give you more speed.
Disclaimer: The first method cited above is considered dark magic and it's totally not recommended (the threading.Lock-likes are preferred in that use case). In general I don't think that changing the thread context switch interval is something to do under normal circumstances. I will paraphrase what Tim Peters already say about metaclasses: changing thread context switch interval is deeper magic than 99% of people are going to need.
Before, the interpreter switched threads every time it completed N virtual instructions, where every instruction could take arbitrary long to complete.
发布评论
评论（2）
一种用途是确保操作以原子方式运行，例如：
另一种用途是在您面临 护航效应（或新 GIL 性能不佳的任何边缘情况）。也许（只是也许）改变上下文切换间隔可以给你带来更快的速度。
免责声明：上面引用的第一种方法被认为是黑魔法，完全不推荐使用（在该用例中，类似
threading.Lock的方法是首选）。一般来说，我不认为在正常情况下改变线程上下文切换间隔是应该做的事情。我将解释 Tim Peters 已经说过的关于元类的话：更改线程上下文切换间隔比 99% 的人需要的更深的魔力。One use will be to make sure that operation(s) run atomically, for example:
Another use case will be to tune your code specially when you're facing the convoy effect (or any edge case where the new GIL give bad performance). Maybe (just maybe) changing the context switch interval can give you more speed.
Disclaimer: The first method cited above is considered dark magic and it's totally not recommended (the
threading.Lock-likes are preferred in that use case). In general I don't think that changing the thread context switch interval is something to do under normal circumstances. I will paraphrase what Tim Peters already say about metaclasses:changing thread context switch interval is deeper magic than 99% of people are going to need.这种方式更加一致和可预测。
以前，解释器每次完成 N 个虚拟指令时都会切换线程，其中每条指令可能需要任意长的时间才能完成。
It's more consistent and predictable this way.
Before, the interpreter switched threads every time it completed N virtual instructions, where every instruction could take arbitrary long to complete.