18862, "ronawho", "Barrier module stabilization - method names", "2021-12-14T20:56:47Z"
Once a barrier is created, the interface is pretty simple. You can either do a single-phase
barrier() call or you can do a split-phase barrier with
notify(). These are pretty standard and the wait/notify is simply an optimization to allow you to do some work while waiting for other tasks to arrive.
We also have
check just lets you ask if the barrier is complete and
reset is a way to change the number of tasks participating in the barrier. Arguably instead of doing a
reset you could just destroy the barrier and create a new one, but that's potentially expensive so I think
reset is also an optimization of sorts. I'm not sure the name is particularly intuitive though. I don't personally know of any use cases for
check, but you could imagine combining it with a split-phase barrier to see if you should keep doing some work on your own or if others have completed the barrier. I'm not sure if
check has any implications for potential implementations (i.e. does it force you into specific implementations that might not be needed if you didn't support it.)
See Barrier module stabilization - overview · Issue #18860 · chapel-lang/chapel · GitHub for comparisons to other languages.