I am picking up C# 4.0 and one of the things which is confusing me, is the barrier concept.
Is this not just like using the WaitAll method of WaitHandle? Doesn't that wait for all threads to finish?
I learnt the barrier construct from this page: http://www.managed-world.com/archive/2009/02/09/an-intro-to-barrier.aspx
However, it seems just like the WaitAll method. What am I missing? What's the difference here?
Thanks.
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.
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.
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.
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.
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;-).