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:

for (int i = 0; i < 1000; i++)
{
 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();
}

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();
}