Using Barrier to Implement Go's Wait Group

Question

I have implemented a WaitGroup class to simulate WaitGroup in Go lang. Then I've found that I can use Barrier in a different manner, to achieve the same thing. My WaitGroup has some additional functionality, but in most scenarios Barrier just would do.

Question: Do you spot any design flaws in this style of using Barrier?

Code:

I have an instance of Barrier:

static Barrier WaitGroupBarrier = new Barrier(0);

Then I define my tasks (or threads) this way in multiple places - so I have not the actual number of tasks/threads:

for (int i = 0; i < 1000; i++) // in multiple places
{
 var t = new Task(() =>
 {
 try
 {
 WaitGroupBarrier.AddParticipant();
 // body
 }
 finally
 {
 WaitGroupBarrier.RemoveParticipant();
 }
 });
 t.Start();
}

And I wait for them to complete, this way:

if (WaitGroupBarrier.ParticipantsRemaining > 0)
{
 Console.WriteLine("waiting...");
 WaitGroupBarrier.SignalAndWait();
}

• Kaveh Shahbazian: The question is about C#; not Go. I am "simulating" this feature of Go, in C#. It's not a comparison. BTW I like Go.
• Kaveh Shahbazian: @svick How can I move this question there? Should I repeat it there or somebody would migrate it? Please guide me.
• svick: Probably the fastest way for you is to ask the question there again and then delete it here. Another option would be to flag it and ask for it to be moved.
• Denys Séguret: OP, if you do this, let a link here in comment so that we can follow the question.
• Intermernet: Yes, I'd like to see the answer to this... My C# skills are a few (read many) years old, and I'd like to see the solution!

Answer 1

if (WaitGroupBarrier.ParticipantsRemaining > 0) {
 WaitGroupBarrier.SignalAndWait();
}

The above is a non-atomic operation. Thus if the if branch gets evaluated and there is one remaining, but finishes before SignalAndWait, then this will throw an exception.