Diferença entre a barreira em C# 4.0 e WaitHandle em C# 3.0?

Question

Estou pegando C# 4.0 e uma das coisas que está me confundindo é o conceito de barreira.

Isso não é apenas como usar o WaitAll método de WaitHandle? Isso não espera que todos os threads terminem?

Aprendi a construção da barreira nesta página: http://www.managed-world.com/archive/2009/02/09/an-intro-to-barrier.aspx

No entanto, parece apenas o WaitAll método. o que estou perdendo? Qual é a diferença aqui?

Obrigado.

Answer 1

It sounds like you are curious as to why a Barrier would be preferred over a WaitHandle + WaitForAll derivative? Both can achieve a similar goal if structured properly.

I'm not extremely familiar with Barrier but one advantage that jumps out at me is a resource issue. To synchronize N threads with a Barrier requires only a single Barrier instance. To synchronize N threads via a WaitHandle and WaitAll requires N handles. These resources are cheap but not free. Reducing the number of resources to synchronize a group of threads has it's advantages.

Answer 2

See Barrier. It waits for a group of multiple threads to reach certain point, instead of one. It is often used in scientific computing and simulation to represent time "ticks."

Imagine a 1000 x 1000 x 1000 grid of cubes representing cubic mile of air. At time zero a given unit cube gets affected by its neighbors' various parameters like temp and pressure. Once everyone computes time 1, you do the same for time 2... You get a weather simulation. Similar story for nuclear simulation.

There's also a variation of barrier called CyclicBarrier where it accepts threads that didn't take off from the start line and let it join back into the group after some time. It's not clear from the documentation whether C# 4's Barrier is a cyclic barrier, but there's a property called ParticipantsRemaining.

Answer 3

Barrier offers a higher level of abstraction and convenience: a single SignalAndWait call is all each thread needs to do, rather than having to know which handle in the array it should signal (or use a mutex to find and increment the "next available spot in the array" and signal that) and to have to first signal and then WaitAll.

In the end of course you can perform the same synchronization task by appropriate use of other synchronization mechanisms, but for such a common usage pattern as Barrier embodies, it's handy to have such a convenient and fool-proof solution already there and neatly packaged up;-).

Answer 4

WaitFor is a Transact SQL statement. It blocks the execution of a batch, stored procedure, or transaction until a specified time or time interval is reached, or a specified statement modifies or returns at least one row.

A Barrier is a synchronization primitive that enforces the stopping of execution between a number of threads or processes at a given point and prevents further execution until all threads or processors have reached the given point.

If you are referring to WaitAll, WaitAll requires you to maintain an array of WaitHandles. In that sense, barrier is a little simpler to use. However, I agree the two methods do look remarkably similar.

Answer 5

The main weakness function WaitAll is a maximum handles limit (only 64 handles can be used) Workaround for the WaitHandle.WaitAll 64 handle limit?

Answer 6

Seems like a counted waithandle to me. Gives you the convenience to say "when the number of threads waiting on this lock becomes X, let them all go." It's nothing you can't do with another construct, but it does seem convenient.