El GIL: qué serializa y qué no vuelve seguro

Qué es

El glosario define el bloqueo global del intérprete (GIL, por sus siglas en inglés) como el mecanismo que usa CPython para garantizar que solo un hilo ejecute bytecode de Python a la vez, lo que hace que el modelo de objetos, incluidos los tipos integrados como dict, sea implícitamente seguro frente al acceso concurrente. El bloqueo se libera durante la E/S bloqueante y también lo libera el código de extensión que opta por hacerlo, y por eso los hilos limitados por E/S se solapan y los limitados por CPU no. Desde la versión 3.13 existe una compilación sin GIL (free-threaded, --disable-gil); la guía de free-threading indica que en ella dict, list y set usan bloqueos internos para comportarse de forma similar a la compilación con GIL, y que el GIL puede activarse automáticamente, con una advertencia impresa, cuando se importa un módulo de extensión en C que no está marcado como compatible con free threading.

Por qué importa

«Python tiene un GIL, así que mi código es seguro entre hilos» es una interpretación errónea muy extendida. El GIL protege las estructuras de datos del intérprete. No protege los invariantes del programa: un hilo puede ser desalojado entre dos bytecodes cualesquiera, y la mayoría de las sentencias se compilan en varios.

Cómo aplicarlo

• Considera insegura toda operación de lectura-modificación-escritura: counter += 1, d[k] = d.get(k, 0) + 1, if key not in cache: cache[key] = compute(). Envuélvelas en with lock:; la documentación recomienda la sentencia with frente al uso manual de acquire()/release().
• Protege un invariante que abarca varios objetos (dos listas que deben mantener la misma longitud) con un único lock, no con un lock por objeto.
• Usa RLock cuando un método con lock llama a otro método con lock del mismo objeto; un Lock simple no es reentrante y bloquea a su propio hilo.
• Pasa el trabajo entre hilos mediante queue.Queue, que gestiona su propio bloqueo.
• No diseñes contando con la atomicidad de operaciones individuales sobre contenedores; solo se cumple en ciertos métodos implementados en C en la compilación por defecto y no es una garantía del lenguaje.
• En una compilación free-threaded mantén exactamente los mismos locks; la guía indica que compartir un mismo iterador entre hilos puede producir elementos duplicados o ausentes.

Trampas

El código que funciona bajo el GIL porque los cambios de hilo son poco frecuentes falla bajo carga o en otra versión. Mantener un lock mientras se llama a código desconocido (callbacks, manejadores de logging, __del__) propicia interbloqueos. Un intérprete free-threaded no demuestra que el GIL esté desactivado: comprueba sys._is_gil_enabled() en tiempo de ejecución, ya que una extensión no preparada puede volver a activarlo.