GIL e hyperthreading

[Hernan Martínez Foffani]

[rosendo]
> ...
> ¿Realmente es tan complicado eliminar este lock?, la
> respuesta es parece que sí, si quieres conservar la opción de
> multiplataforma.

No es solo por eso, hay mas.
- el multithread en pyhton usa la implementación
nativa de cada plataforma, como bien dices.
- python es extensible y embebible.
- en python todos los objetos son GLOBALES.

Dado que python usa el threading del S.O. los cambios de
contexto se pueden producir *en cualquier momento* de la
ejecución de codigo C.
Sin el GIL cualquiera que haga una extensión debería
preveer la programación en multihilos aunque ni siquiera
la necesite (puede que otra extension o el mismo python,
sí lo hagan.)  El GIL facilita hacer extensiones,
supongo que no habría tantas de otro modo.

Aun dentro de python la situación no es mejor.
Evidentemente como no se puede quitar el lock --siempre
será necesario algun mecanismo de contencion-- lo que
se podría hacer es que la granularidad sea menor.
El problema es que todos los objetos en python son
globales, por lo que habría que proteger casi todos
los accesos.  Lo logico es esperar que se pierda
performance en vez de ganarla.
Los lenguajes que tienen mecanismos de privilegios de
acceso lo tienen mas fácil: no es necesario poner y
quitar locks en variables privadas.

[Chema]
>> ¿No sería factible bloquear sólo el acceso a una
>> determinada zona "compartida" en lugar de bloquear
>> todo el intérprete? ¿Realmente es tan complicado eliminar
>> este lock? (Por ejemplo jython no lo tiene).

Para bien y para mal está todo compartido en python.
java no lo tiene por el nivel de protección nativa al
lenguaje.
Desconozco cómo se ha implementado en jython la
"globalidad" de los objetos, si esa es tu pregunta.
Tampoco hay problemas con las extensiones porque
el multithread no es del S.O., es el del propio JVM.
Una vez fuera del entorno java, con JNI, estás fuera del
entorno multihilos (o la propia extensión debería
implementar el suyo propio.)

> Y como "escape", entiendo que va a resultar mejor utilizar "forking"
> en linux en sistemas multiprocesador pero, ¿qué método sería el más
> apropiado para intercambiar información entre los procesos sin tener
> que echar mano de las bases de datos?

Supongo que lo apropiado dependerá de la aplicación,
de la portabilidad.  Hay montones de tecnologías para eso.
Es una de las cosas donde las distintas versiones de Unix
empezaron a diverger mas y mas.
Tienes (o tenías porque es casi prehistoria) pipes,
sockets AF_UNIX, los IPC de SystemV (memoria compartida,
semaforos y mensajes), pipes como dispositivos, archivos mmap y
vaya a saber cuantas cosas mas.

Lo que menciono Francesc es muy moderno y cientifico.
A mi me superado porque yo soy viejito y me he quedado en mmap
que no da muchos problemas y es mas o menos portable. ;-)

Saludos,
-H.