了解使用锁和pythongil进行抢占式多任务处理吗?

2024-03-28 15:18:49 发布

您现在位置:Python中文网/ 问答频道 /正文

我正在通读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的先发制人?或者这不是这句话所指的吗?在


Tags: thenolockgroksoasit语句
1条回答
网友
1楼 · 发布于 2024-03-28 15:18:49

我问了这篇文章的作者,这归结为放弃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.

相关问题 更多 >