Un bloqueo de intérprete global ( GIL ) es un mecanismo utilizado en intérpretes de lenguaje de computadora para sincronizar la ejecución de subprocesos de modo que solo se pueda ejecutar un subproceso nativo a la vez. [1] Un intérprete que usa GIL siempre permite que se ejecute exactamente un hilo a la vez, incluso si se ejecuta en un procesador de múltiples núcleos . Algunos intérpretes populares que tienen GIL son CPython y Ruby MRI .
Conceptos de antecedentes técnicos
Un bloqueo de intérprete global (GIL) es un bloqueo de exclusión mutua mantenido por un subproceso de intérprete de lenguaje de programación para evitar compartir código que no es seguro para subprocesos con otros subprocesos. En implementaciones con GIL, siempre hay un GIL para cada proceso de intérprete .
Las aplicaciones que se ejecutan en implementaciones con un GIL pueden diseñarse para usar procesos separados para lograr un paralelismo completo, ya que cada proceso tiene su propio intérprete y, a su vez, tiene su propio GIL. De lo contrario, el GIL puede ser una barrera significativa para el paralelismo.
Ventajas
Las razones para emplear un bloqueo de intérprete global incluyen:
- mayor velocidad de los programas de un solo subproceso (no es necesario adquirir o liberar bloqueos en todas las estructuras de datos por separado),
- fácil integración de bibliotecas de C que generalmente no son seguras para subprocesos,
- facilidad de implementación (tener un solo GIL es mucho más simple de implementar que un intérprete sin bloqueo o uno que usa bloqueos de grano fino).
Una forma de sortear un GIL es crear un intérprete separado por hilo, lo cual es demasiado caro con la mayoría de los idiomas.
Inconvenientes
El uso de un bloqueo de intérprete global en un idioma limita efectivamente la cantidad de paralelismo alcanzable a través de la concurrencia de un solo proceso de intérprete con múltiples subprocesos. Si el proceso se compone casi exclusivamente de código interpretado y no realiza llamadas fuera del intérprete que bloquean durante largos períodos de tiempo (lo que permite que ese hilo libere el GIL mientras procesan), es probable que haya muy poco aumento en velocidad cuando se ejecuta el proceso en una máquina multiprocesador . Debido a la señalización con un subproceso vinculado a la CPU, puede causar una desaceleración significativa, incluso en procesadores individuales. [2]
Ejemplos de
Algunas implementaciones de lenguaje que implementan un bloqueo de intérprete global son CPython , la implementación más utilizada de Python , [3] [4] y Ruby MRI , la implementación de referencia de Ruby (donde se llama Global VM Lock).
Los equivalentes basados en JVM de estos lenguajes ( Jython y JRuby ) no utilizan bloqueos de intérprete globales. IronPython e IronRuby se implementan sobre el Dynamic Language Runtime de Microsoft y también evitan el uso de GIL. [5]
Un ejemplo de lenguaje interpretado sin GIL es Tcl , que se utiliza en la herramienta de evaluación comparativa HammerDB. [6]
Ver también
Referencias
- ^ "GlobalInterpreterLock" . Consultado el 30 de noviembre de 2015 .
- ^ David Beazley (11 de junio de 2009). "Dentro de Python GIL" (PDF) . Chicago: Grupo de usuarios de Python de Chicago . Consultado el 7 de octubre de 2009 .
- ^ Shannon -jj Behrens (3 de febrero de 2008). "Concurrencia y Python" . Diario del Dr. Dobb . pag. 2 . Consultado el 12 de julio de 2008 .
El GIL es un candado que se usa para proteger todas las secciones críticas en Python. Por lo tanto, incluso si tiene varias CPU, solo un hilo puede estar haciendo cosas "pythony" a la vez.
- ^ "Manual de referencia de la API de Python / C: estado del hilo y bloqueo global del intérprete" . Archivado desde el original el 14 de septiembre de 2008 . Consultado el 15 de agosto de 2014 .
- ^ "IronPython en python.org" . python.org . Consultado el 4 de abril de 2011 .
IronPython no tiene GIL y el código multiproceso puede usar procesadores de múltiples núcleos.
- ^ "Conceptos y Arquitectura de HammerDB" . HammerDB. 2018-11-30 . Consultado el 10 de mayo de 2020 .
Es importante comprender desde el principio que HammerDB está escrito en TCL debido a las capacidades únicas de subprocesamiento que brinda TCL.