O GIL: o que ele serializa e o que ele não torna seguro

O que é

O glossário define o global interpreter lock como o mecanismo que o CPython usa para garantir que apenas uma thread execute bytecode Python por vez, o que torna o modelo de objetos, incluindo tipos nativos como dict, implicitamente seguro contra acesso concorrente. O lock é liberado durante operações de I/O bloqueantes e por código de extensão que opte por isso; é por esse motivo que threads limitadas por I/O se sobrepõem e as limitadas por CPU, não. Desde a versão 3.13 existe uma build free-threaded (--disable-gil); segundo o guia de free threading, nela dict, list e set usam locks internos para se comportar de forma semelhante à build com GIL, e o GIL pode ser reativado automaticamente, com a exibição de um aviso, quando se importa um módulo de extensão em C que não esteja marcado como compatível com free threading.

Por que importa

"Python tem GIL, então meu código é thread-safe" é um equívoco comum. O GIL protege as estruturas de dados do interpretador, não as invariantes do programa: uma thread pode ser interrompida entre quaisquer dois bytecodes, e a maioria das instruções é compilada em vários deles.

Como aplicar

• Considere insegura toda operação de leitura-modificação-escrita: counter += 1, d[k] = d.get(k, 0) + 1, if key not in cache: cache[key] = compute(). Envolva-as em with lock:; a documentação recomenda a instrução with em vez de chamar acquire()/release() manualmente.
• Proteja uma invariante que envolva vários objetos (por exemplo, duas listas que precisam manter o mesmo tamanho) com um único lock, e não com um lock por objeto.
• Use RLock quando um método protegido por lock chamar outro método protegido do mesmo objeto; um Lock comum não é reentrante e bloqueia a própria thread.
• Passe trabalho entre threads por meio de queue.Queue, que faz o próprio controle de lock.
• Não baseie o design na atomicidade de operações isoladas em contêineres: ela só vale para determinados métodos implementados em C na build padrão e não é uma garantia da linguagem.
• Em uma build free-threaded, mantenha exatamente os mesmos locks; o guia afirma que compartilhar um mesmo iterador entre threads pode gerar elementos duplicados ou ausentes.

Armadilhas

Código que funciona sob o GIL porque as trocas de thread são raras acaba falhando sob carga ou em outra versão. Manter um lock enquanto se chama código desconhecido (callbacks, handlers de logging, __del__) abre caminho para deadlocks. Usar um interpretador free-threaded não prova que o GIL está desativado: verifique sys._is_gil_enabled() em tempo de execução, pois uma extensão não preparada pode reativá-lo.