El subproceso de Python parece ejecutar subprocesos

Question

Estoy tratando de usar subprocesos en un proyecto de Python en el que estoy trabajando, pero los subprocesos no parecen comportarse como deberían en mi código. Parece que todos los subprocesos se ejecutan secuencialmente (es decir, el subproceso2 se inicia después de que finaliza el subproceso 1, ambos no se inician al mismo tiempo). Escribí un script simple para probar esto, y eso también ejecuta hilos secuencialmente.

import threading 

def something(): 
    for i in xrange(10): 
     print "Hello" 

def my_thing(): 
    for i in xrange(10): 
     print "world" 

threading.Thread(target=something).start() 
threading.Thread(target=my_thing).start() 

Aquí está la salida que recibo de ejecutarlo:

Hello 
Hello 
Hello 
Hello 
Hello 
Hello 
Hello 
Hello 
Hello 
Hello 
world 
world 
world 
world 
world 
world 
world 
world 
world 
world 

El mismo comportamiento se observa con mucho mayor número de iteraciones de los bucles.

Intenté buscar en la web y SO más antiguas, pero no encontré nada que me ayudara. ¿Puede alguien indicar qué problema tiene este código?

Answer 1

Actualmente en python, los hilos se cambian después de ejecutar una cierta cantidad especificada de instrucciones de bytecode. No se ejecutan al mismo tiempo. Solo tendrá subprocesos ejecutándose en paralelo cuando uno de ellos llame a algún módulo intensivo de E/S o que no tenga Python que pueda liberar GIL (bloqueo de intérprete global).

Estoy bastante seguro de que obtendrá la salida mezclada si aumenta el número de bucles a algo así como 10000. Recuerde que simplemente generar el segundo hilo también lleva "mucho" tiempo.

Answer 2

En el tiempo que toma el segundo hilo para iniciar los primeros bucles de hilo e imprime ya.

Aquí se ve así, se puede ver el segundo hilo comenzando después de que el primero emitió algunos saludos.

Hello 
Hello 
Hello 
Hello 
Hello 
Helloworld 

Helloworld 

Helloworld 

Helloworld 

Helloworld 

world 
world 
world 
world 
world 

Btw: Su ejemplo no es significativo en absoluto. La única razón para Threads es IO, y IO es lento. Cuando se agrega un poco de dormir para simular IO que debería funcionar como se esperaba: aparece

import threading 
from time import sleep 

def something(): 
    for i in xrange(10): 
     sleep(0.01) 
     print "Hello" 

def my_thing(): 
    for i in xrange(10): 
     sleep(0.01) 
     print "world" 

threading.Thread(target=something).start() 
threading.Thread(target=my_thing).start() 

una mezcla salvaje:

worldHello 

Helloworld 

Helloworld 

worldHello 

Helloworld 

Helloworld 

worldHello 

Helloworld 

worldHello 

Helloworld 

Answer 3

Esto realmente depende de planificador de su sistema operativo, el procesador.
Aparte de eso, se sabe que los hilos de CPython no son perfectos debido al GIL (PDF), lo que, en resumen, significa que muchas veces los hilos se ejecutan secuencialmente, o algo por el estilo.

Answer 4

El comportamiento también puede cambiar dependiendo de si el sistema está utilizando tiene un solo procesador o varios procesadores, como se explica en this talk por David Beazley.

Como dice viraptor, el primer subproceso liberará el GIL después de ejecutar sys.getcheckinterval() bytecodes (100 de manera predeterminada). Para resumir crudamente lo que dice David Beazley, en un sistema de procesador único, el segundo hilo tendrá la oportunidad de hacerse cargo. Sin embargo, en un sistema multinúcleo, el segundo subproceso puede estar ejecutándose en un núcleo diferente, y el primer subproceso intentará readquirir el bloqueo y probablemente tenga éxito, ya que el sistema operativo no habrá tenido tiempo de cambiar procesadores. Esto significa que en un sistema multinúcleo con una hebra enlazada a la CPU, es posible que los otros subprocesos nunca se vean.

El camino a seguir es agregar una sentencia sleep a ambos lazos para que dejen de serlo CPU vinculada.