Le GIL : ce qu'il sérialise et ce qu'il ne rend pas sûr

Ce que c'est

Le glossaire définit le verrou global de l'interpréteur (global interpreter lock, GIL) comme le mécanisme utilisé par CPython pour garantir qu'un seul thread exécute du bytecode Python à la fois, ce qui rend implicitement sûr face aux accès concurrents le modèle objet, y compris les types intégrés tels que dict. Le verrou est relâché autour des entrées-sorties bloquantes et, par extension, du code natif qui en fait le choix, ce qui explique que les threads dominés par les entrées-sorties se chevauchent alors que les threads dominés par le calcul ne le font pas. Un build sans GIL (--disable-gil) existe depuis la version 3.13 ; le guide du free-threading indique que, sur un tel build, dict, list et set utilisent des verrous internes pour se comporter de façon similaire au build avec GIL, et que le GIL peut être réactivé automatiquement, avec un avertissement affiché, lorsqu'un module d'extension C non marqué comme prenant en charge le free-threading est importé.

Pourquoi c'est important

« Python a un GIL, donc mon code est thread-safe » est une lecture erronée courante. Le GIL protège les structures de données de l'interpréteur. Il ne protège pas les invariants du programme : un thread peut être interrompu entre deux instructions de bytecode quelconques, et la plupart des instructions du langage se compilent en plusieurs.

Comment l'appliquer

• Traiter toute séquence de lecture-modification-écriture comme non sûre : counter += 1, d[k] = d.get(k, 0) + 1, if key not in cache: cache[key] = compute(). Les envelopper dans with lock: ; la documentation recommande l'instruction with plutôt que des appels manuels à acquire()/release().
• Protéger par un seul verrou, et non par un verrou par objet, un invariant qui s'étend sur plusieurs objets (deux listes qui doivent rester de même longueur).
• Utiliser RLock lorsqu'une méthode verrouillée appelle une autre méthode verrouillée du même objet ; un simple Lock n'est pas réentrant et bloque son propre thread.
• Faire transiter le travail entre threads par queue.Queue, qui gère son propre verrouillage.
• Ne pas concevoir son code autour de l'atomicité d'opérations isolées sur un conteneur ; elle ne vaut que pour certaines méthodes implémentées en C sur le build par défaut et n'est pas une garantie du langage.
• Sur un build sans GIL, conserver exactement les mêmes verrous ; le guide indique que partager un même itérateur entre threads peut produire des éléments dupliqués ou manquants.

Pièges

Un code qui fonctionne sous le GIL parce que les changements de contexte sont rares échoue sous charge ou sur une autre version. Conserver un verrou pendant l'appel à du code inconnu (fonctions de rappel, gestionnaires de journalisation, __del__) invite les interblocages. Qu'un interpréteur soit un build sans GIL ne prouve pas que le GIL est désactivé : vérifier sys._is_gil_enabled() à l'exécution, car une extension non préparée peut le réactiver.