On Mon, Feb 13, 2023 at 4:00 PM Chris Ryan via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> I don't think the language should include your idea. It is generally ill
> advised/non-standard functionality and is only for covering what iI
> consider a design usage flaw with your update/change/notification
> mechanism. It does not add any useful functionality that is not already
> available through the use of otherwise simple normal coding techniques.
>
> I believe using a technique demonstrated in this Godbolt link does
> everything, all the flavors, of all the options, including function
> grouping, without any extra overhead, other than what you were already
> asking for, without changing the language. Plus by directly including it
> in your code, shows intent and it does not hide any functionality.
> https://godbolt.org/z/5v1MoMKfz
>

"Yes, and..." Looking at that code, I see that it suffers from the same
problem I keep asking Frederick to address: he hasn't said what the code is
supposed to do in the "failure" case. Your implementation uses a variable
named "unblocked," as if there's a mode in which the code would block and
wait for... something... to happen. But in fact your code never blocks. If
a reentrant call is attempted, the... whole function body... is just...
skipped?!
(1) There's no way this is what the programmer actually intended.
(2) How would you skip the body of a function that has a non-void return
type?
Frederick has said that the functionality of his feature would be to
"prevent" calls that are "reentrant." Defining what that means has two
parts:
(A) Define what makes a call "reentrant." This is relatively well addressed.
(B) Define what it means to "prevent" a call. This has not been addressed
at all.

Compare to std::once_flag, which "prevents" multiple callers from entering
the same critical section at once: what it means by "prevent" is "everyone
who's not the owner of the once_flag must block and wait until the current
owner completes the block; if successful, all waiters unblock and skip the
critical section; if failed, exactly one waiter unblocks and attempts the
critical section again."
https://quuxplusone.github.io/blog/2020/10/23/once-flag/
Frederick needs to describe the semantics of his new synchronization
primitive in the same sense. Who blocks, how do they get unblocked, etc.

(Frederick has also said things like "The block only applies to..." which
makes me think he's unclear on the English jargon meaning of the verb "to
block"/"to wait" in concurrency *in general*.)

–Arthur