On Tuesday, 22 October 2019 08:14:18 PDT Andrey Semashev via Std-Discussion
wrote:
> > You're probably right, but it's easy to see how it would happen if the
> > atomic is a member of a class.
>
> Not really. A member of a class can be accessed from multiple places,
> including via different pointers and references. Even if you only access
> it from a single method of the class, that method can be called
> concurrently. I don't see how a compiler would be able to prove that
> that doesn't happen, ever. And if that indeed clearly doesn't happen
> then that is probably another pathological case where atomic is not needed.

But the object of that class may be a local variable, which means it can't be
accessed asynchronously from any other thread unless its address is passed to
that thread. If all of the members of the class are inline, the compiler can
know whether that happened or not and thus conclude when it didn't.

> Atomics are used to synchronize threads (obviously), so when an atomic
> is used, that by itself is a clear sign that concurrency is in place.

No, it's an indication that concurrency could be in place. The compiler can
still reason that it wasn't.

This kind of reasoning is quite useful for atomic reference counts. If the
variable was never shared with another thread, then the compiler should be
able to keep track of the count and reduce the number of expensive, atomic
operations to increment and decrement it.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel System Software Products