On Wed, 22 Feb 2023 at 07:17, Frederick Virchanza Gotham via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Wed, Feb 22, 2023 Jonathan Wakely wrote:
> >
> > Why would you use an atomic_flag this way?
>
>
> In my desktop GUI programs, I have event handlers that process the
> clicking of a button, or the ticking of a box, and sometimes I use an
> 'atomic_flag' to make sure that these functions are not re-entered --
> not just by other threads but also by the same thread.
>
>
> Shortly afterward, Thiago Macieira posted:
> > That is not a good implementation. It's neither a spinlock nor a futex.
>
>
> I don't see anything wrong with waiting for an atomic to change.
>
>
> > The problem is that The Right Thing is to use a mutex, so just use a
> mutex or
> > a binary_semaphore.
>
>
> If you double-lock a mutex, the behaviour is undefined. A recursive
> mutex is of no use either because we don't want the same thread to be
> able to re-enter.
>

So you'd prefer to just have a guaranteed deadlock instead? That's a valid
choice for your GUI program, but not something that is general-purpose and
worth adding to the standard library.