Понимание упреждающей многозадачности с блокировками и Python GIL?

Question

Я читаю Grok The GIL, и в обсуждении о блокировке есть следующее утверждение.

До тех пор, пока ни один поток не удерживает блокировку, пока он спит, выполняет ли ввод-вывод или какую-либо другую операцию сброса GIL, вы должны использовать самые грубые, самые простые из возможных блокировок. Другие потоки не могли работать параллельно в любом случае.

Это приходит сразу после обсуждения упреждающей многозадачности. Что мешает упреждающему сбросу GIL во время блокировки? Или это не то, на что ссылается это утверждение?

Answer 1

Я спросил автора статьи, и это сводится к разнице между отбрасыванием GIL, потому что вы ожидаете внешней операции по сравнению с внутренним preemtion: https://opensource.com/article/17/4/grok-gil

Привет! Ничто не мешает потоку упреждающе отбрасывать GIL, пока он удерживает блокировку. Давайте назовем этот поток A и предположим, что есть также поток B. Если поток A удерживает блокировку и получает приоритет, то, возможно, поток B мог бы работать вместо потока A.

Если нить B ожидает блокировки, которую удерживает нить A, то нить B не ожидает GIL. В этом случае поток A получает GIL сразу же после его сброса, и поток A продолжает работу.

Если поток B не ожидает блокировки, которую держит поток A, тогда поток B может получить GIL и запустить.

Однако я хочу сказать о грубых блокировках: никакие два потока не могут выполнять Python параллельно из-за GIL. Поэтому использование мелкозернистых замков не улучшает пропускную способность. Это отличается от языка, такого как Java или C, где мелкозернистые блокировки обеспечивают больший параллелизм и, следовательно, большую пропускную способность.

Я все еще нуждался в некотором уточнении, и он подтвердил это:

Если я правильно вас понимаю, целью оператора, на который я ссылался, было избежать использования блокировок вокруг внешних операций, где вы могли бы затем блокировать несколько потоков, если все они зависели от этой блокировки.

В превентивном примере Поток A ничем не заблокирован, поэтому обработка просто идет вперед и назад, подобно кооперативной многозадачности.