Diferencia entre la barrera en C# 4.0 y WaitHandle en C# 3.0?

Question

Estoy recogiendo C# 4.0 y una de las cosas que me confunde es el concepto de barrera.

¿No es esto simplemente como usar el método WaitAll de WaitHandle? ¿No espera eso a que terminen todos los hilos?

aprendí la construcción de la barrera de esta página: http://www.managed-world.com/archive/2009/02/09/an-intro-to-barrier.aspx

Sin embargo, parece que al igual que el método WaitAll. ¿Qué me estoy perdiendo? ¿Cuál es la diferencia aquí?

Gracias.

Answer 1

Parece que tiene curiosidad sobre por qué una Barrera sería preferible a una derivada WaitHandle + WaitForAll? Ambos pueden lograr un objetivo similar si están estructurados adecuadamente.

No estoy muy familiarizado con Barrier, pero una ventaja que se me viene encima es un problema de recursos. Para sincronizar N hilos con una barrera, solo se necesita una única instancia de barrera. Para sincronizar N subprocesos a través de un WaitHandle y WaitAll se requieren N identificadores. Estos recursos son baratos pero no gratuitos. La reducción de la cantidad de recursos para sincronizar un grupo de hilos tiene sus ventajas.

Answer 2

Ver Barrier. Espera a que un grupo de hilos múltiples alcance cierto punto, en lugar de uno. A menudo se usa en computación y simulación científica para representar "marcas" de tiempo.

Imagine una cuadrícula de cubos de 1000 x 1000 x 1000 que representa la milla cúbica de aire. En el tiempo cero, un cubo dado de una unidad se ve afectado por los diversos parámetros de sus vecinos, como la temperatura y la presión. Una vez que todos calculan el tiempo 1, haces lo mismo para el tiempo 2 ... Obtienes una simulación meteorológica. Una historia similar para la simulación nuclear.

También hay una variación de la barrera llamada CyclicBarrier donde acepta hilos que no despegaron de la línea de inicio y lo dejan volver a unirse al grupo después de un tiempo. No está claro en la documentación si la barrera C# 4 es una barrera cíclica, pero hay una propiedad llamada ParticipantsRemaining.

Answer 3

WaitFor es una instrucción Transact SQL. Bloquea la ejecución de un lote, procedimiento almacenado o transacción hasta que se alcanza un intervalo de tiempo o tiempo específico, o una instrucción especificada modifica o devuelve al menos una fila.

Una barrera es una primitiva de sincronización que impone la detención de la ejecución entre una serie de subprocesos o procesos en un punto determinado y evita su ejecución hasta que todos los subprocesos o procesadores hayan alcanzado el punto especificado.

Si se refiere a WaitAll, WaitAll requiere que mantenga una matriz de WaitHandles. En ese sentido, la barrera es un poco más simple de usar. Sin embargo, estoy de acuerdo en que los dos métodos se ven notablemente similares.

Answer 4

Parece un indicador de espera contado para mí. Te da la conveniencia de decir "cuando el número de subprocesos que esperan en este bloqueo se convierta en X, déjalos ir todos". No es nada que no puedas hacer con otra construcción, pero parece conveniente.

Answer 5

Barrier ofrece un mayor nivel de abstracción y conveniencia: una sola llamada SignalAndWait es lo que cada thread necesita hacer, en lugar de tener que saber qué manejador en la matriz debe señalar (o usar un mutex para encontrar e incrementar el " el siguiente punto disponible en la matriz "y señal eso" y tener que hacer primero la señal y luego WaitAll.

Al final del curso puede realizar la misma tarea de sincronización mediante el uso apropiado de otros mecanismos de sincronización, pero para un patrón de uso común como Barrier encarna, es útil tener una solución tan práctica ya prueba de errores ya cuidadosamente embalado ;-).

Answer 6

La principal función WaitAll debilidad es un máximo límite de identificadores (sólo 64 mangos pueden ser utilizados) Workaround for the WaitHandle.WaitAll 64 handle limit?