[PATCH] D65718: [LangRef] Document forward-progress requirement

[Ralf via Phabricator via llvm-commits]

RalfJung added inline comments.


================
Comment at: llvm/docs/LangRef.rst:2497
+(including but not limited to accessing inaccessible memory, volatile or
+atomic memory access, or other forms of thread synchronization). Failure to
+cause a side-effect in a finite amount of time results in undefined behavior.
----------------
jfb wrote:
> efriedma wrote:
> > jfb wrote:
> > > A relaxed atomic load is a sufficient side-effect?
> > We want to consider a busy-wait loop like "while (foo){}", where "foo" is an atomic variable, as making forward progress; otherwise, there isn't any way to write such a loop.  We also want to allow erasing dead atomic loads.
> > 
> > We might need to modify the definition of a side-effect to make this work.
> Right, I'm trying to understand what guarantees LLVM offers, and if they're the same or more than C++.
> Where it makes sense I'd like this documented, with references.
> 
> http://eel.is/c++draft/intro.progress
> http://eel.is/c++draft/intro.multithread#intro.races-3
> 
A loop `while (/* relaxed load */ == 0) {}` followed by an acquire-fence should definitely //not// be optimized away. That is a perfectly reasonable pattern to establish synchronization though fences and relaxed accesses.

The C++ standard specifically says "atomic operations" in loops are good enough, and while one can argue about whether a relaxed load synchronizes (it sometimes does, as in the above), I think we can agree that it is an atomic operation?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65718/new/

https://reviews.llvm.org/D65718