Les crashs dev d'un passionné
Python -A la découverte du GIL
25 nov. 2019
Le Global Intercepter Lock est un mécanisme appelé Mutex permettant d'exécuter uniquement 1 thread python à un moment donné.
C'est tout simplement un bit qui bloque une zone de mémoire, car les threads dans un même process partage la même zone mémoire. L'ordre d'exécution des threads étant géré par le CPU lui-même.
En résumé un seul thread python peut tourner dans 1 seul CPU au même instant.
L'interpréteur CPython utilise ce mécanisme dans son core car la gestion aux objets n'est pas thread safe. Ce mécanisme est mis en place afin de rendre thread safe l'exécution du code python.
Derrière chaque process python il y a un GIL qui gère les threads.
Il existe d'autres interpréteurs comme Jython qui n'ont pas ce souci de GIL mais ce n'est pas l'implémentation la plus choisie (généralement CPython). Attention si vous utilisez un autre interpréteur, certaines librairies peuvent ne plus fonctionner correctement.
Lors d'opération I/O le GIL est libéré (lock release), donc d'autres threads disponibles peuvent être exécutés. Dans ce cas le multi thread est intéressant en python.
Lors de la sollicitation de CPU (calcul important, traitement vidéo ...) le GIL vérifie périodiquement (tous les 100 tick) quel thread est éligible à l'exécution.
Dans les autres cas il n'est pas nécessairement intéressant de faire du threading car les threads sont lancés à tour de rôles par le thread maître
En effet c'est le thread maître qui implémente le GIL et gère les autres threads du processus.
Mais alors pourquoi mettre en place le GIL ? Cela est historique car auparavant les serveurs étaient équipés d'un seul processeur et le multi threading n'était pas d'actualité.
La philosophie de python étant de faire des choses simples, le langage utilise un lock générale pour que le développeur ne se soucis pas des problèmes de concurrences.
Mais avec le développement des multi cœur au sein d'un CPU le GIL est venu rajouter une complexité dans la gestion des programmes multi thread. Cela étant le cœur de python il est difficile de le remettre en question simplement.
Cependant dans la version 3.9 de python une évolution va avoir lieu. En effet une nouvelle librairie régie par la PEP 554 permettrait de lancer plusieurs interpréteurs au sein d'un même processus et donc potentiellement de lancer plusieurs threads dans ce même processus. Ce serait l'interpréteur qui porterait le GIL.
La release de cette version python 3.9 est prévue pour la fin 2020.
En attendant il faut vérifier que notre programme à un intérêt à utiliser les librairies de gestion des threads.
Et il est important de connaître la différence entre du code parallélisable et concurrent. Un code s'exécutant de manière concurrente fait référence à une ressource partagée contrairement à un code parallèle qui exécute les tâches de manière totalement indépendante.
Un code concurrent exécutera des tâches de manière alternative par exemple sur une machine avec 1 seul core
Un code parallèle va exécuter en même temps les différentes tâches dans des cores CPU différents.
Voici un comparatif de performance
blog comments powered by Disqus
C'est tout simplement un bit qui bloque une zone de mémoire, car les threads dans un même process partage la même zone mémoire. L'ordre d'exécution des threads étant géré par le CPU lui-même.
En résumé un seul thread python peut tourner dans 1 seul CPU au même instant.
L'interpréteur CPython utilise ce mécanisme dans son core car la gestion aux objets n'est pas thread safe. Ce mécanisme est mis en place afin de rendre thread safe l'exécution du code python.
Derrière chaque process python il y a un GIL qui gère les threads.
Il existe d'autres interpréteurs comme Jython qui n'ont pas ce souci de GIL mais ce n'est pas l'implémentation la plus choisie (généralement CPython). Attention si vous utilisez un autre interpréteur, certaines librairies peuvent ne plus fonctionner correctement.
Lors d'opération I/O le GIL est libéré (lock release), donc d'autres threads disponibles peuvent être exécutés. Dans ce cas le multi thread est intéressant en python.
Lors de la sollicitation de CPU (calcul important, traitement vidéo ...) le GIL vérifie périodiquement (tous les 100 tick) quel thread est éligible à l'exécution.
Dans les autres cas il n'est pas nécessairement intéressant de faire du threading car les threads sont lancés à tour de rôles par le thread maître
En effet c'est le thread maître qui implémente le GIL et gère les autres threads du processus.
Mais alors pourquoi mettre en place le GIL ? Cela est historique car auparavant les serveurs étaient équipés d'un seul processeur et le multi threading n'était pas d'actualité.
La philosophie de python étant de faire des choses simples, le langage utilise un lock générale pour que le développeur ne se soucis pas des problèmes de concurrences.
Mais avec le développement des multi cœur au sein d'un CPU le GIL est venu rajouter une complexité dans la gestion des programmes multi thread. Cela étant le cœur de python il est difficile de le remettre en question simplement.
Cependant dans la version 3.9 de python une évolution va avoir lieu. En effet une nouvelle librairie régie par la PEP 554 permettrait de lancer plusieurs interpréteurs au sein d'un même processus et donc potentiellement de lancer plusieurs threads dans ce même processus. Ce serait l'interpréteur qui porterait le GIL.
La release de cette version python 3.9 est prévue pour la fin 2020.
En attendant il faut vérifier que notre programme à un intérêt à utiliser les librairies de gestion des threads.
Et il est important de connaître la différence entre du code parallélisable et concurrent. Un code s'exécutant de manière concurrente fait référence à une ressource partagée contrairement à un code parallèle qui exécute les tâches de manière totalement indépendante.
Un code concurrent exécutera des tâches de manière alternative par exemple sur une machine avec 1 seul core
Un code parallèle va exécuter en même temps les différentes tâches dans des cores CPU différents.
Voici un comparatif de performance