On Wednesday, 20 July 2022 15:44:56 PDT Marcin Jaczewski via Std-Discussion
wrote:
> Then it needs use that flush/update for every operation to maintain
> C++ memory model.

Not really. C++ does not say anything about the timing of when changes are
made visible from one thread to another, only about the coherency of the
happens-before sequence and what is required to be observable if other
happenings have been observed.

It's perfectly valid for a lone operation on an atomic to sit on one core's
cache for a century and never be observed by any other, so long as this atomic
is updated again by any other.

> For some CPU it could be impossible to use C++ atomics.
> But that is irrelevant, we only discuss CPU that can follow or have
> greater garatees than C++ give.

We adapt C++ to what CPUs actually do.

> Only matter if implementation of `store` and `load` have exactly the
> same behavior as required by standard.

Indeed.

> It could be even implemented by halting other cores if there is no other
> way.

For 80386 and 80486, atomic operations in SMP systems were implemented by
locking the entire memory bus (hence the "LOCK" prefix), preventing other
processors from accessing memory at all. Cache on 80386 was optional.

> if cache had old data then it was, how do you work with read-acquire
> and write-release without flushing cache?

Acquire does not require the other data to have become visible. It only
requires that, if you do observe it, whatever was released prior to the
matching store is also visible to you (the exact wording is more complex than
this, of course).

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering