18864, "ronawho", "Barrier module stabilization - waiting policy", "2021-12-14T20:57:05Z"
Today the barrier initializer has a barrierType argument.
proc init(numTasks: int, barrierType: BarrierType = BarrierType.Atomic, reusable: bool = true)
This lets users select between atomics or syncs to implement the atomic. The reason we care is that atomics will spin wait and will likely have lower latency, but use more CPU and syncs will have higher latency but use less CPU.
I think keeping this concept about active waiting vs blocking is important in the longer term, but I'm not sure we should make the enum about the implementation details. I wonder if this could instead be a "waiting policy" enum or something more generic that describes the intent rather than the implementation. If we keep an enum of sorts to control this behavior, I think we should make it param. It being non-param currently requires dynamic dispatch to select the implementation and I think we need barriers to have as little overhead as possible. I also wonder whether we need this control for the initial stabilization effort. It would seem easiest to get rid of the waiting policy for now, stabilize, and then we can add it back in later as we need it and have time to optimize.