multithreading - thread - sync lock c#

Ventajas de usar variables de condición sobre mutex (3)

Está buscando demasiada superposición en dos cosas separadas pero relacionadas: un mutex y una variable de condición.

Un enfoque de implementación común para un mutex es usar un indicador y una cola. La bandera indica si el mutex está en manos de alguien (un semáforo de un solo conteo también funcionaría), y la cola rastrea qué hilos están en línea esperando para adquirir el mutex exclusivamente.

Una variable de condición se implementa luego como otra cola atornillada a ese mutex. Los hilos que se pusieron en línea para esperar para adquirir el mutex pueden, por lo general, una vez que lo han adquirido, ser voluntarios para salir del frente de la fila y entrar en la cola de condición. En este punto, tienes dos conjuntos separados de camareros:

Aquellos que esperan adquirir el mutex exclusivamente
Aquellos que esperan que la variable de condición sea señalada

Cuando un hilo que contiene el mutex señala exclusivamente la variable de condición, para lo cual asumiremos por ahora que es una señal singular (que desencadena no más de un hilo en espera) y no una transmisión (desencadenando todos los hilos de espera), el primer hilo en la cola de variables de condición se reenvía al frente (generalmente) de la cola mutex. Una vez que el hilo que actualmente contiene el mutex, generalmente el hilo que señala la variable de condición, renuncia al mutex, el siguiente hilo en la cola mutex puede adquirirlo. Ese siguiente hilo en línea habrá sido el que estuvo a la cabeza de la cola de variables de condición.

Hay muchos detalles complicados que entran en juego, pero este boceto debería darle una idea de las estructuras y operaciones en juego.

Me preguntaba cuál es el beneficio de rendimiento de usar variables de condición sobre bloqueos de mutex en pthreads.

Lo que encontré es: "Sin variables de condición, el programador necesitaría tener hilos de sondeo continuo (posiblemente en una sección crítica), para verificar si se cumple la condición. Esto puede consumir muchos recursos ya que el hilo estaría continuamente ocupado en este actividad. Una variable de condición es una forma de lograr el mismo objetivo sin votación ". (https://computing.llnl.gov/tutorials/pthreads)

Pero también parece que las llamadas mutex son de bloqueo (a diferencia de los bloqueos de giro). Por lo tanto, si un subproceso (T1) no puede obtener un bloqueo porque algún otro subproceso (T2) tiene el bloqueo, T1 queda inactivo por el SO y se activa solo cuando T2 libera el bloqueo y el SO le da a T1 el bloqueo. El hilo T1 realmente no sondea para obtener el bloqueo. A partir de esta descripción, parece que no hay beneficio de rendimiento al usar variables de condición. En cualquier caso, no hay votación involucrada. El sistema operativo de todos modos proporciona el beneficio que el paradigma de variable de condición puede proporcionar.

¿Puedes explicar lo que realmente sucede? No es muy claro para mí :(

¡Muchas gracias!

Una variable de condición permite señalar un hilo cuando ocurre algo de interés para ese hilo.

Por sí mismo, un mutex no hace esto.

Si solo necesita exclusión mutua, entonces las variables de condición no hacen nada por usted. Sin embargo, si necesita saber cuándo sucede algo, entonces las variables de condición pueden ayudar.

Por ejemplo, si tiene una cola de elementos para trabajar, tendrá un mutex para garantizar que las partes internas de la cola sean consistentes cuando acceda a los diversos hilos de productor y consumidor. Sin embargo, cuando la cola está vacía, ¿cómo sabrá un hilo de consumo cuando algo está ahí para que funcione? Sin algo así como una variable de condición, necesitaría sondear la cola, tomar y liberar el mutex en cada encuesta (de lo contrario, un hilo de productor nunca podría poner algo en la cola).

El uso de una variable de condición le permite al consumidor encontrar que cuando la cola está vacía puede simplemente esperar en la variable de condición que indica que a la cola le han puesto algo. Sin sondeo: ese hilo no hace nada hasta que un productor pone algo en la cola, y luego señala la condición de que la cola tiene un nuevo elemento.

Si busca rendimiento, comience a leer acerca de los algoritmos de sincronización de hilos "sin bloqueo / sin bloqueo". Se basan en operaciones atómicas, que gcc tiene la amabilidad de proporcionar. Operaciones gráficas de búsqueda de gcc. Nuestras pruebas mostraron que podíamos incrementar un valor global con múltiples hilos utilizando magnitudes de operación atómica más rápido que con un mutex. Aquí hay un código de muestra que muestra cómo agregar elementos ay desde una lista vinculada desde múltiples hilos al mismo tiempo sin bloqueo.

Para los hilos que duermen y despiertan, las señales son mucho más rápidas que las condiciones. sigwait pthread_kill para enviar la señal, y sigwait para dormir el hilo. Probamos esto también con el mismo tipo de beneficios de rendimiento. Aquí hay un código de ejemplo.