atomic types are way too different from Lockable types to make it worth to try and define a kind of common abstraction on both.

As an analogy, this proposal have resemblance with the statement "why would we need unique_lock in the first place, as we could already define a specialization unique_ptr<Mutex>". Short answer is both the their fundamental intent and behaviour diverges in to many ways that there is no benefit in trying to abstract unique_lock and unique_ptr under the same abstraction.

In more details, lock_guars and unique_lock 's main purpose is as an RAII wrapper over a *BasicLockable* (or *Lockable* type). atomic types themselves have trivial destructors and do not hold any resource.

Furthermore, *BasicLockable* in essence means the type has a lock function which blocks the invoking execution agent (but doesn't further require that this operation be atomic or that a previous unlock call synchronizes with this lock operation). But on the other hand, atomic types' basic purpose is to operate in a *lock free* way with guaranteed atomicity; all of their basic operations complete in a bounded number of steps (typically, most scalar types will be, and atomic_flag will necessarily be lock free). Even busy waiting, is fundamentally different from blocking as the former case deadlocking or live locking cannot occur and at least one of the program threads is guaranteed to progress (although, it may happen that some individual thread starve).

In short, atomic vs Lockable have somewhat contradicting behavior:

 -Lockable types: blocking, not necessarily atomic

 - atomic types: non blocking, necessarily atomic

Julien V.

On February 21, 2023 7:02:11 p.m. EST, Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> wrote:
>I think 'lock_guard' and 'unique_lock' should be usable with atomic_flag.
>
>The constructor would do:
>
> while ( f.test_and_set() ) f.wait(true);
>
>And the destructor would do:
>
> f.clear();
>
>Furthermore, 'try_lock' would simply be:
>
> return false == f.test_and_set();
>
>Also defer_lock, adopt_lock and try_to_lock would be easily
>implementable as constructor arguments.
>--
>Std-Proposals mailing list
>Std-Proposals_at_[hidden]
>https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals