What is the potential risk with this code?
Update

OP has since updated question so this answer makes no sense any more WRT question asked!! Those edits have also been lost in migration from stack overflow it seems.

Purely from a concurrency perspective and not commenting on if the design is fit for purpose:



Newly added Volatile

You do not understand this, I am not going to go into why, just read up on stack overflow/MSDN or don't use it. As I remember you had a readonly on the instance. That was correct.

In general don't lock(this), because (although not in this case... yet) this can also be locked from external code (lock(BarrierCount.getInstance())), and that allows deadlocks to occur. Although no deadlock is possible here as the methods are guaranteed to return.

Instead add a specific lock object:

private readonly object _lock = new object();




Note

readonly not volatile. readonly makes it clear to readers/modifiers that the reference is safe to use from multiple threads. It also stops modifiers from changing the reference (unless they remove the readonly, but they should make them think twice at least).

In WaitForAll you read count without a lock. Suggest you add a private GetCount() which locks.

I'm not sure how this is used, the setCount is presumably called once before the work commences. If the tasks have started and there is any risk in them calling workDone before setCount then it won't ever reach zero.

I would loose setCount in favour of an IncrementCount() method called before starting each task.



But

You should look at Task.WaitAll before you do more on this.