Multithreading usages for CountdownEvent vs Barrier?

Question

Looking at the Barrier class , it allows n threads to rendezvous at a point in time :

static Barrier _barrier = new Barrier(3);
static void Main()
{
    new Thread(Speak).Start();
    new Thread(Speak).Start();
    new Thread(Speak).Start();
}
static void Speak()
{
    for (int i = 0; i < 5; i++)
    {
        Console.Write(i + " ");
        _barrier.SignalAndWait();
    }
}
//OUTPUT: 0 0 0 1 1 1 2 2 2 3 3 3 4 4 4

But so does the CountdownEvent class :

static CountdownEvent _countdown = new CountdownEvent(3);
static void Main()
{
    new Thread(SaySomething).Start("I am thread 1");
    new Thread(SaySomething).Start("I am thread 2");
    new Thread(SaySomething).Start("I am thread 3");
    _countdown.Wait(); // Blocks until Signal has been called 3 times
    Console.WriteLine("All threads have finished speaking!");
}
static void SaySomething(object thing)
{
    Thread.Sleep(1000);
    Console.WriteLine(thing);
    _countdown.Signal();
}


// output : 
I am thread 3
I am thread 1
I am thread 2
All threads have finished speaking!

So it seems that the Barrier blocks until n threads are meeting while the CountdownEvent is also blocking until n threads are signaling.

It's kind of confusing( to me ) to learn from it , when should I use which.

Question:

In which (real life scenario) should I need to choose using Barrier as opposed to CountdownEvent (and vice versa) ?

Answer 1

There are some interesting things to note about the two:

• A CountdownEvent does not have an explicit post-action associated with it; a Barrier does.
• A CountdownEvent and a Barrier with one phase are roughly equivalent so can be used interchangeably.
• A Barrier can have multiple phases. As each phase completes, the post-phase action is executed; when that action completes, the next phase begins.

There is a similar question on SO that discusses this behavior, but for the Java equivalents of the C# classes. The answers give several examples, which are valid for the C# equivalents.

That said, consider a real world scenario: checking 3 credit sources for a potential loan to a home buyer. Let's say you don't want to make a decision until you receive all 3 credit scores and evaluate them. You could use either a CountdownEvent (with the code after the Wait() checking the scores) or a single-phased barrier with the score checking code action.

Here's where Barrier would be a better choice: let's say the loan officer wants to also check the home buyer's SO reputation score (because expert users get better credit!) and two other social scores, but only after the credit scores are retrieved (because hey, we don't want check social media if we don't have to).

The neat thing about the Barrier is you can move through the phases in a single method call, which keeps the logic compact and tidy:

var barrier = new Barrier(participantCount: 3, b => LogScoreAndPossiblyEvaluate(b));
var credit = new int[3];
var social = new int[3];

void LogScoreAndPossiblyEvaluate(Barrier b)
{
    Log.Info("Got scores for {b.CurrentPhaseNumber == 1 ? "credit" : "social"} phase");
     ...
    if (b.CurrentPhaseNumber == 2 && SomeComplexCalculationWithSixScores() == LoanResult.Approved)
        LoanMoney(); 
}

...

for (int i=0; i<3; i++)
    Task.Run(() => {
        credit[i] = GetCreditScore(CreditSource(i);
        barrier.SignalAndWait();

        social[i] = GetSocialScore(SocialSource(i);
        barrier.SignalAndWait();

        // all phases done at this point 
    });