On Thu, Feb 2, 2023 at 12:49 PM Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Thursday, 2 February 2023 03:59:10 PST Frederick Virchanza Gotham via
> Std-
> Proposals wrote:
> > This new feature could be kept simple, or tt could made be very
> > complex with extra parameters to do stuff like:
> > * Prevent reentry by other threads but not by the same thread
> > * Prevent reentry by the same thread but not by other threads
> > * Prevent reentry by all threads except the one with the specified
> > thread::id
>
> You've mostly implemented this already as library solutions.
>

One might say, "completely implemented." This does seem like a
synchronization primitive, analogous to `std::once_flag`, `std::mutex`, and
`std::condition_variable`.
@Frederick: Your next step should be to write this "reentry guard" as a
class type with a well-defined API. You already know that it wants to
protect a section of code: that's RAII — it's going to call some member
function of the reentry-guard in the RAII type's constructor, and some
other member function of the reentry-guard in the RAII type's destructor.
What are those member functions going to be named? (For the sake of
argument, let's call them "lock" and "unlock.") What are they going to do?
In particular, what is the "lock" function going to do if the reentry-guard
is already locked? It can't block and wait for the reentry-guard to become
available, because that would result in deadlock. Should it throw an
exception? (Should it just return a boolean `false` to mean "sorry, you
can't enter here"? I don't think that's compatible with RAII.)

Ultimately I predict you're going to end up reinventing
`std::recursive_mutex`... but let's do the work and find out.

–Arthur