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 wait() and 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 and reset calls. 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.