C++ Logo

std-discussion

Advanced search

Re: Should std::atomic<T*> have operator->?

From: Ryan Nicholl <exaeta_at_[hidden]>
Date: Mon, 21 Oct 2019 18:41:43 +0000
std::atomic_ref is the closest viable option, proposed for C++20.

atomic<T*>.dereference_load() and atomic<T*>.dereference_store() would be cool, but this is not possible on most architectures AFAIK. We could emulate it with a global mutex, but I don't think that's an option.

Ryan Nicholl
678-358-7765

-------- Original Message --------
On Oct 21, 2019, 11:36, Thiago Macieira via Std-Discussion wrote:

> On Monday, 21 October 2019 00:44:24 PDT Jeremy Ong via Std-Discussion wrote:
>> You have now done an atomic load 3 times and it is possible that stores or
>> loads to foo have occurred in between. The pattern for atomic usage is to
>> typically load once, perform a change, and possibly compare/swap in a loop
>> in a manner that prevents ABA bugs.
>
> If the compiler can inline those three function calls, it may also coalesce
> the three loads into one. AFAIK, no compiler currently does it, but it could.
> If it can't inline, then the regular rules of visibility apply and if the
> atomic pointer's own address is not accessible by other threads and the called
> functions, coalescing can happen again.
>
> But if it can change, then the code is actually optimal, since you do have tot
> reload it every time. Except that you have to write:
>
> foo.load()->do_one_thing();
> foo.load()->do_another_thing();
> foo.load()->do_a_final_thing();
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel System Software Products
>
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion

Received on 2019-10-21 13:44:03