Supposons que j'ai une fonction d'extension C qui fait quelque chose complètement indépendant de l'interprète Python. Y a-t-il une raison pas em> pour libérer le gil? Par exemple, existe-t-il une raison pour ne pas écrire de code comme celui-ci (mis à part des problèmes tels que la lisibilité et éviter la micro-optimisation - des choses qui sont importantes, Mais pas vraiment pertinent pour ma question)? P> Py_BEGIN_ALLOW_THREADS
a = 1 + 1;
Py_END_ALLOW_THREADS
4 Réponses :
Le gil est un mutex ordinaire. Le coût de la verrouillage ou du déverrouillage d'un non content em> Mutex est extrêmement faible, pas beaucoup plus que le coût de la modification d'une variable globale. Toutefois, si vous verrouillez et déverrouillez très souvent un mutex contesté, le coût du mutex peut devenir significatif. Donc, ce n'est généralement pas une bonne idée: P> very_long_computation_requires_gil();
Py_BEGIN_ALLOW_THREADS;
a = a + i;
Py_END_ALLOW_THREADS;
very_long_computation_also_requires_gil();
Si vous avez une fonction d'extension C qui fait quelque chose complètement indépendant de l'interprète Python, alors libérer le gil est généralement une bonne idée. Le seul inconvénient est en attente de récupérer le gil. À Python 3.2, vous devez attendre un minimum de 1/20 du second.
Y a-t-il une raison pour ne pas libérer le gil?
Si l'extension C appelle le code non re-entrant, vous pouvez avoir des problèmes si plusieurs threads Python appellent à l'extension en même temps. Donc, vous voudrez peut-être éviter de libérer le gil dans de telles extensions pour protéger contre cette activité (bien sûr, vous pouvez créer votre propre mutex au niveau du python ou le niveau C pour y parvenir sans affecter d'autres threads).
ou si le gil ne doit-il être libéré que pour plus de code intensivité de la CPU?
Une autre raison principale de la libération du gil est lorsque vous appelez une extension C qui bloque (comme un blocage lu sur une prise) pour permettre à d'autres threads de s'exécuter. C'est exactement ce qui se passe lorsque l'interprète Python exécute elle-même une opération de blocage dans un fil.
Les experts sont toujours modifiés et tester à propos de GIL.
Ce sont de nouvelles idées sur un ancien problème: Enlèvement d'appartements intérieurs -patch
Vous pouvez également envisager d'essayer Python sans empiler (pas de gil) ou pypy (python avec compilateur juste à temps).
Je ne comprends pas la voix basse. Ma réponse est une référence à une discussion best-of toutes, où Guido et d'autres développeurs comparent différents problèmes et différentes solutions sur GIL. Aucun ne répond ici toucher ce niveau de détails et de savoir-faire.
C'est simple: votre message ne répond pas à la question. (Notez que ce n'était pas moi qui a voté-voté, bien que)
Ferdinand, je suis d'accord, mon lien n'est pas une réponse complète, mais je pense toujours que c'est mieux que les suppositions des autres utilisateurs. De plus, je suggère Stackless et Pypy, n'est-ce pas une réponse pratique?
Vous voyez, l'OP sait sur le gil et connaît probablement aussi des alternatives. Mais la question est très spécifique: à l'aide de CPPHON tel qu'il est, lors de la rédaction d'une extension en C, est-ce une bonne idée de libérer souvent le gil ou existe-t-il des descentes? C'est pourquoi votre réponse n'est pas utile du tout (comparez-la à la réponse acceptée). Mais ne vous inquiétez pas trop du bowvote.