Date: Fri, 26 May 2023 10:32:44 -0700
On Friday, 26 May 2023 07:01:18 PDT John Platts via Std-Proposals wrote:
> Adding lock-free atomic operations that can operate on any valid pointer to
> a suitably-aligned type such as lock_free_atomic_load_32,
> lock_free_atomic_store_32, lock_free_compare_exchange_weak_32, and
> lock_free_compare_exchange_strong_32 addresses issues that are not
> addressed by the std::memcpy and std::bit_cast operations.
I'm missing something: what's the difference between what you're proposing and
what's already in std::atomic and std::atomic_ref? You're saying that "it's
equivalent to" the std::atomic_ref example, but you didn't say why you can't
just use that.
> Adding lock-free atomic operations that can operate on any valid pointer to
> a suitably-aligned type such as lock_free_atomic_load_32,
> lock_free_atomic_store_32, lock_free_compare_exchange_weak_32, and
> lock_free_compare_exchange_strong_32 addresses issues that are not
> addressed by the std::memcpy and std::bit_cast operations.
I'm missing something: what's the difference between what you're proposing and
what's already in std::atomic and std::atomic_ref? You're saying that "it's
equivalent to" the std::atomic_ref example, but you didn't say why you can't
just use that.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Received on 2023-05-26 17:32:47