2011-09-11 10 views

Respuesta

4

Un uso será para asegurarse de que la operación (s) ejecutar atómicamente, por ejemplo:

sw_interval = sys.getswitchinterval() 
try: 
    # Setting the switch interval to a very big number to make sure that their will be no 
    # thread context switching while running the operations that came after. 
    sys.setswitchinterval(sys.maxint) 
    # Expressions run here will be atomic .... 
finally: 
    sys.setswitchinterval(sw_interval) 

Otro caso de uso será para afinar su código especialmente cuando se está frente al borde convoy effect (o cualquier caso donde el nuevo GIL da un mal rendimiento). Tal vez (solo tal vez) cambiar el intervalo de cambio de contexto puede darle más velocidad.

responsabilidad: El primer método es situada por encima de considerar oscura magia y totalmente no es recomendable (los threading.Lock -likes se prefieren en ese caso de uso). En general, no creo que cambiar el intervalo de cambio de contexto del hilo sea algo que se debe hacer bajo circunstancias normales. Parafrasearé lo que Tim Peters ya dice sobre las metaclases: changing thread context switch interval is deeper magic than 99% of people are going to need.

+0

Cuando una aplicación está vinculada a IO, ¿la aumentaría _ o _decretaría_? –

+2

@Matt: en realidad, tener solo hilos enlazados IO no supone un problema porque cada vez que un hilo ejecuta una instrucción IO bound, libera el GIL, pero el problema se puede ver cuando se utiliza un hilo IO con hilo de CPU como se explica en este problema (http://bugs.python.org/issue7946) en un caso como este (de nuevo) tal vez la disminución del intervalo de cambio puede conducir a un mejor rendimiento porque los hilos de IO no tendrán que esperar mucho más si no bloquearon en absoluto. – mouad

+0

+1 para hacer referencia a la magia 'oscura' en este método –

Cuestiones relacionadas