New Issue: Barrier module stabilization - should re-usability be selectable

18865, "ronawho", "Barrier module stabilization - should re-usability be selectable", "2021-12-14T20:57:09Z"

Today the barrier initializer has a reusable argument:

proc init(numTasks: int, barrierType: BarrierType = BarrierType.Atomic, reusable: bool = true)

If the barrier doesn't need to be reusable, we can optimize a little bit of work out. It's not obvious to me how much time this saves in practice, and we don't have any current non-reusable use-cases.

Other languages (C++, Java) have different types called latches. If we want to keep this non-reusable optimization I think it's an open question for whether it should be a different type or just a param argument. Other languages don't have params so in order to actually optimize any branches out they need a different type, but we don't have to do that ourselves.

So the open question here is if we want to keep the non-reusable optimization in and if so how do we expose that to users. My preference for stabilization would be to just remove the feature for now and it can always be added back in as a different type or an optional argument.