Differenza tra barriera in C# 4.0 e WaitHandle in C# 3.0?

Question

Sto raccogliendo C# 4.0 e una delle cose che mi confonde, è il concetto di barriera.

Non è come utilizzare il metodo WaitAll di WaitHandle? Non aspetta che finiscano tutti i thread?

ho imparato il costrutto barriera da questa pagina: http://www.managed-world.com/archive/2009/02/09/an-intro-to-barrier.aspx

Tuttavia, sembra proprio come il metodo WaitAll. Cosa mi manca? Qual è la differenza qui?

Grazie.

Answer 1

Sembra che tu sia curioso di sapere perché una barriera sarebbe preferibile a una derivata WaitHandle + WaitForAll? Entrambi possono raggiungere un obiettivo simile se strutturati correttamente.

Non ho molta familiarità con Barrier ma un vantaggio che mi salta è un problema di risorse. Per sincronizzare N thread con una barriera richiede solo una singola istanza Barriera. Per sincronizzare N thread tramite WaitHandle e WaitAll richiede N handle. Queste risorse sono economiche ma non gratuite. Ridurre il numero di risorse per sincronizzare un gruppo di thread ha i suoi vantaggi.

Answer 2

Vedere Barrier. Aspetta che un gruppo di thread multipli raggiunga un certo punto, invece di uno. Viene spesso utilizzato nel calcolo scientifico e nella simulazione per rappresentare i "battiti" del tempo.

Immaginate una griglia di cubi di 1000 x 1000 x 1000 che rappresenta il miglio cubo dell'aria. Al tempo zero, un dato cubo di unità viene influenzato dai vari parametri dei suoi vicini come temperatura e pressione. Una volta che tutti calcolano il tempo 1, si fa lo stesso per il tempo 2 ... Si ottiene una simulazione meteorologica. Storia simile per la simulazione nucleare.

C'è anche una variante di barriera denominata CyclicBarrier dove accetta i thread che non sono decollati dalla linea di partenza e lo fanno rientrare nel gruppo dopo un po 'di tempo. Dalla documentazione non è chiaro se la Barriera C# 4 sia una barriera ciclica, ma esiste una proprietà chiamata ParticipantsRemaining.

Answer 3

WaitFor è un'istruzione Transact SQL. Blocca l'esecuzione di un batch, una stored procedure o una transazione fino al raggiungimento di un intervallo di tempo o di tempo specificato, oppure un'istruzione specificata modifica o restituisce almeno una riga.

Una barriera è una primitiva di sincronizzazione che impone l'arresto dell'esecuzione tra un numero di thread o processi in un determinato punto e impedisce l'ulteriore esecuzione finché tutti i thread o processori non hanno raggiunto il punto specificato.

Se si fa riferimento a WaitAll, WaitAll richiede di mantenere un array di WaitHandles. In questo senso, la barriera è un po 'più semplice da usare. Tuttavia, sono d'accordo che i due metodi sembrano molto simili.

Answer 4

Sembra una mancia d'attesa conteggiata per me. Ti dà la comodità di dire "quando il numero di thread in attesa su questo blocco diventa X, lasciali andare tutti". Non è niente che non puoi fare con un altro costrutto, ma sembra conveniente.

Answer 5

Barrier offre un livello più alto di astrazione e convenienza: una singola chiamata SignalAndWait è tutta la lunghezza di ogni thread, piuttosto che dover sapere quale handle nell'array deve essere segnalato (oppure utilizzare un mutex per trovare e incrementare il " prossimo punto disponibile nell'array "e segnalarlo) e di dover prima segnalare e quindi WaitAll.

Alla fine naturalmente è possibile eseguire la stessa operazione di sincronizzazione con l'uso appropriato di altri meccanismi di sincronizzazione, ma per un tale modello di utilizzo comune come Barrier incarna, è comodo avere tale soluzione conveniente e infallibile già lì e ben confezionato ;-).

Answer 6

La funzione principale debolezza è WaitAll un massimo maniglie limite (solo 64 le maniglie possono essere utilizzati) Workaround for the WaitHandle.WaitAll 64 handle limit?