我正在阅读Grok The GIL在关于锁定的讨论中，有如下的表述。
So long as no thread holds a lock while it sleeps, does I/O, or some other GIL-dropping operation, you should use the coarsest, simplest locks possible. Other threads couldn't have run in parallel anyway.
它是在关于抢占式多任务处理的讨论之后出现的。当你有锁时，什么可以防止 GIL 被抢先丢弃？或者这不是该声明所指的内容？
最佳答案
我问了这篇文章的作者，它归结为因为等待外部操作而删除 GIL 与内部抢占之间的区别:https://opensource.com/article/17/4/grok-gil#comment-136186
Hi! Nothing prevents a thread from preemptively dropping the GIL while it holds a lock. Let's call that Thread A, and let's say there's also a Thread B. If Thread A holds a lock and gets preempted, then maybe Thread B could run instead of Thread A.
If Thread B is waiting for the lock that Thread A is holding, then Thread B is not waiting for the GIL. In that case Thread A reacquires the GIL immediately after dropping it, and Thread A continues.
If Thread B is not waiting for the lock that Thread A is holding, then Thread B might acquire the GIL and run.
My point about coarse locks, however, is this: no two threads can ever execute Python in parallel, because of the GIL. So using fine-grained locks doesn't improve throughput. This is in contrast to a language like Java or C, where fine-grained locks allow greater parallelism, and therefore greater throughput.
我仍然需要一些澄清，他确实证实了这一点:
If I'm understanding you correctly, the intent of the statement I referenced was to avoid using locks around external operations, where you could then block multiple threads, if they all depended on that lock.
For the preemptive example, Thread A isn't blocked by anything externally, so the processing just goes back and forth similar to cooperative multitasking.
关于python - 了解使用锁和 Python GIL 的抢占式多任务处理？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/44981958/