Date: Wed, 22 Feb 2023 07:17:11 +0000
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.
I don't see why a binary_semaphore would better than an atomic_flag here.
>
> 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.
I don't see why a binary_semaphore would better than an atomic_flag here.
Received on 2023-02-22 07:17:24