Der GIL: Was er serialisiert und was er nicht sicher macht

Worum es geht

Das Glossar definiert den Global Interpreter Lock als den Mechanismus, mit dem CPython sicherstellt, dass jeweils nur ein Thread Python-Bytecode ausführt, wodurch das Objektmodell – einschliesslich eingebauter Typen wie dict – implizit gegen gleichzeitigen Zugriff geschützt ist. Der Lock wird bei blockierendem I/O sowie bei Erweiterungscode, der sich dafür entscheidet, freigegeben; deshalb überlappen sich I/O-gebundene Threads, CPU-gebundene hingegen nicht. Seit 3.13 gibt es einen Free-Threaded-Build (--disable-gil); der Leitfaden zu Free Threading hält fest, dass darin dict, list und set interne Locks verwenden, um sich ähnlich wie im GIL-Build zu verhalten, und dass der GIL automatisch mit einer ausgegebenen Warnung aktiviert werden kann, wenn ein C-Erweiterungsmodul importiert wird, das nicht als Free-Threading-fähig gekennzeichnet ist.

Warum es wichtig ist

„Python hat einen GIL, also ist mein Code threadsicher" ist eine verbreitete Fehldeutung. Der GIL schützt die Datenstrukturen des Interpreters. Er schützt nicht die Invarianten des Programms: Ein Thread kann zwischen zwei beliebigen Bytecodes ausgesetzt werden, und die meisten Anweisungen werden in mehrere davon übersetzt.

So wird es angewendet

• Jedes Read-Modify-Write als unsicher behandeln: counter += 1, d[k] = d.get(k, 0) + 1, if key not in cache: cache[key] = compute(). Diese in with lock: einschliessen; die Dokumentation empfiehlt die with-Anweisung gegenüber manuellem acquire()/release().
• Eine Invariante, die sich über mehrere Objekte erstreckt (zwei Listen, die gleich lang bleiben müssen), mit einem Lock schützen, nicht mit einem Lock pro Objekt.
• RLock verwenden, wenn eine gesperrte Methode eine andere gesperrte Methode desselben Objekts aufruft; ein einfacher Lock ist nicht reentrant und blockiert seinen eigenen Thread.
• Arbeit zwischen Threads über queue.Queue übergeben, das seine eigene Sperrung vornimmt.
• Nicht auf die Atomizität einzelner Container-Operationen bauen; sie gilt nur für bestimmte, in C implementierte Methoden im Standard-Build und ist keine Garantie der Sprache.
• In einem Free-Threaded-Build genau dieselben Locks beibehalten; der Leitfaden hält fest, dass das Teilen eines einzigen Iterators zwischen Threads doppelte oder fehlende Elemente liefern kann.

Stolpersteine

Code, der unter dem GIL funktioniert, weil Wechsel selten sind, versagt unter Last oder auf einer anderen Version. Einen Lock zu halten, während unbekannter Code aufgerufen wird (Callbacks, Logging-Handler, __del__), begünstigt Deadlocks. Ein Free-Threaded-Interpreter beweist nicht, dass der GIL abgeschaltet ist: zur Laufzeit sys._is_gil_enabled() prüfen, da eine nicht darauf vorbereitete Erweiterung ihn wieder einschalten kann.