Explicación de texto en la que rosca en "C# 3.0 en una cáscara de nuez"

Question

Mientras lee C# 3.0 en una cáscara de nuez por Joseph y Ben Albahari, me encontré con el siguiente párrafo (página 673, primer párrafo de la sección titulada "de señalización con Esperar y pulso")

"El clase monitor proporciona otra señalización construir a través de dos métodos estáticos, Espere y pulso. El principio es que usted escriba la lógica de señalización usando banderas y campos personalizados (incluidos en cerradura declaraciones), y luego introduzca Espere y comandos de pulso para mitigar el giro de la CPU. La ventaja de este enfoque de bajo nivel es que con sólo Espera, pulso, y la declaración bloqueo, se puede lograr la funcionalidad de AutoResetEvent, ManualResetEvent, y Semáforo, así como WaitHandle métodos estáticos WaitAll y WaitAny. Por otra parte, Wait y pulso puede ser susceptible en situaciones en las todas las manijas de esperar son desafiados con parsimonia."

Mi pregunta es, ¿cuál es la interpretación correcta de la última frase?

• una situación con un gran número decente/de espera, donde se encarga de WaitOne() sólo ocasionalmente se llama en cualquier mango de espera determinado.
• Una situación con un número decente/gran cantidad de identificadores de espera en los que raramente se bloquea más de un hilo en un identificador de espera particular.
• Alguna otra interpretación.

También agradeceríamos ejemplos ilustrativos de tales situaciones y quizás cómo y/o por qué se manejan de manera más eficiente a través de Wait and Pulse en lugar de por otros métodos.

¡Gracias!

Editar: me encontré con el texto online here

Answer 1

Lo que esto quiere decir es que hay algunas situaciones en las que esperar y pulso proporciona una solución simple que esperar asas.En general, esto ocurre cuando:

• El camarero, más que el notificador, decide cuándo desbloquear
• La condición de bloqueo implica algo más que una simple bandera (quizás varias variables)

Puede todavía use los controles de espera en estas situaciones, pero Wait/Pulse tiende a ser más simple. Lo bueno de Wait/Pulse es que Wait libera el bloqueo subyacente mientras espera. Por ejemplo, en el siguiente ejemplo, estamos _x e _y la lectura dentro de la seguridad de una cerradura - y sin embargo, que el bloqueo se libera a la espera para que otro hilo puede actualizar esas variables:

lock (_locker) 
{ 
    while (_x < 10 && _y < 20) Monitor.Wait (_locker); 
} 

otro hilo puede entonces actualizar _x e _y atómicamente (en virtud de la cerradura) y después del pulso de la señal al camarero:

lock (_locker) 
{ 
    _x = 20; 
    _y = 30; 
    Monitor.Pulse (_locker); 
} 

la desventaja de Espera/pulso es que es más fácil de hacerlo mal y cometer un error (por ejemplo, actualizando una variable y olvidando a Pulse). En situaciones en las que un programa con identificadores de espera es igualmente simple para un programa con Espera/Pulso, recomiendo ir con controladores de espera por ese motivo.

En términos de eficiencia/consumo de recursos (que creo que usted estaba aludiendo), Wait/Pulse suele ser más rápido y más ligero (ya que tiene una implementación administrada). Sin embargo, esto rara vez es un gran problema en la práctica. Y en ese punto, Framework 4.0 incluye versiones manejadas de bajo costo de ManualResetEvent y Semaphore (ManualResetEventSlim y SemaphoreSlim).

Framework 4.0 también ofrece muchas más opciones de sincronización que reducen la necesidad de Espera/Pulso:

• CountdownEvent
• Barrera
• PLINQ/Paralelismo de datos (AsParallel, Parallel.Invoke, Parallel.For, Parallel.ForEach)
• Tareas y continuaciones

Todos estos son mucho más altos de levitación el de Wait/Pulse y IMO son preferibles para escribir código confiable y mantenible (suponiendo que resuelvan la tarea a mano).