GIL e hyperthreading

[Jesus Cea Avion]

Chema Cortes wrote:
> El problema sigue siendo que los objetos son "globales", y no puedes
> restrigir su acceso (mejor dicho, sus "accesores"). Aunque ocultes
> atributos, sólo tendrá efecto para los accesos por parte de objetos de
> esa clase.

En vez de tener un GIL global, podrías tener un lock lectura/escritura
por objeto. O un "pool" de locks compartidos por todos los objetos (por
ejemplo, 1024 locks y a cada objeto python le corresponde un lock en
función de su "hash()").

El problema de este esquema es:

a) Pérdida de eficiencia en entornos mono CPU, aunque en entornos
multicpu la ganancia sería lineal.

b) Complejidad.

c) Problemas con las extensiones. Habría que reprogramar la mayoría.

d) Habría que detectar "deadlocks" y decidir qué hacer en ese caso.
Sería preferible emplear un sistema de prevención de "deadlocks", no de
"resolución" de "deadlocks" a posteriori.

Es decir, no es algo trivial, pero opino que Python debería planteárselo
en serio. Con máquinas SMP cada vez más populares, el no poner
aprovechar la mitad de los recursos no solo es un crimen, sino que
resulta una desventaja competitiva importante.

PS: Los esquemas multiproceso ayudan cuando ayudan, pero no son
aplicables en todos los casos.

-- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea en argo.es http://www.argo.es/~jcea/ _/_/    _/_/  _/_/    _/_/  _/_/
                                      _/_/    _/_/          _/_/_/_/_/
PGP Key Available at KeyServ   _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz