Subprocesamiento múltiple, cuándo ceder frente a dormir

Question

Para aclarar la terminología, el rendimiento se produce cuando el subproceso abandona su intervalo de tiempo. Mi plataforma de interés son los hilos POSIX, pero creo que la pregunta es general.

Supongamos que tengo un patrón de consumidor/productor. Si quiero acelerar tanto al consumidor como al productor, ¿cuál es mejor usar, dormir o ceder? Estoy principalmente interesado en la eficiencia del uso de cualquiera de las funciones.

Answer 1

La forma "correcta" de codificar un productor/consumidor es hacer que el consumidor espere los datos del productor. Puede lograr esto utilizando un objeto de sincronización como un Mutex. El consumidor va a Wait en el mutex, lo que bloquea su ejecución hasta que los datos estén disponibles. A su vez, el productor señalará el mutex cuando los datos estén disponibles, lo que activará el hilo del consumidor para que pueda comenzar a procesarse. Esto es más eficiente que sleep tanto en términos de:

• utilización de la CPU (no hay ciclos se desperdician), y
• tiempo de ejecución (ejecución comienza tan pronto como se dispone de datos, no cuando está prevista una rosca para despertar arriba).

Dicho esto, he aquí un análisis de rendimiento vs sueño que usted solicitó. Es posible que necesite utilizar dicho esquema si por algún motivo esperar la salida no es factible:

Depende de la cantidad de tráfico que recibe; si los datos se reciben y procesan constantemente, podría considerar realizar un rendimiento. Sin embargo, en la mayoría de los casos esto dará como resultado un ciclo "ocupado" que pasa la mayor parte del tiempo inútilmente despertando el hilo para verificar si algo está listo.

Es probable que desee dormir por un corto período de tiempo (quizás por menos de un segundo, usando usleep) O incluso mejor utilizar un objeto de sincronización como un mutex para indicar que los datos están disponibles.

Answer 2

Una buena razón para dormir en lugar de ceder es cuando hay mucha contención en una sección crítica específica. Digamos, por ejemplo, intentas adquirir dos bloqueos y hay mucha contención en ambos bloqueos. Aquí puede usar sleep para emplear un retroceso exponencial. Esto permitiría que cada intento fallido de pseduo alejase al azar para permitir que otro subproceso tenga éxito.

Ceder en esta situación no ayuda mucho porque la perspectiva de un retroceso aleatorio puede aumentar la probabilidad de que no ocurra la inanición del hilo.

Editar: Aunque sé que esto no es necesariamente específico de Java. La implementación de Java de Thread.sleep(0) tiene el mismo efecto de Thread.yield() En ese punto es más una cuestión de estilo.

Answer 3

dormir y el rendimiento no es lo mismo. Cuando se llama a la suspensión, el proceso/subproceso le da a la CPU otro proceso/subproceso durante un período de tiempo determinado.

yield cede la CPU a otro hilo, pero puede devolver inmediatamente si no hay otros hilos que esperan CPU.

Por lo tanto, si desea acelerar, por ejemplo, al transmitir datos a intervalos regulares, la función que debe utilizar es dormir o nanosleep.

Si se necesita sincronización entre el productor/consumidor, debe usar una espera mutex/condicional.

Answer 4

En Java, algunas implementaciones de JVM tratan Thread.yield() como no-op, lo que significa que puede no tener ningún efecto. Llamar a Thread.sleep() no significa necesariamente que el programador deba ceder la CPU a otro hilo; esto también depende de la implementación. Puede cambiar de contexto a otro hilo que está esperando o puede que no para amortizar el costo asociado con el cambio de contexto.