llvm dev - Apr 2020 - Permitted success/failure orderings for atomic compare_exchange

A question has come up on how to interpret the wording of LLVM's
documentation regarding the possible memory ordering for success and
failure of atomic compare_exchange operations.
>From the LLVM reference:
"The success and failure ordering
<https://llvm.org/docs/LangRef.html#ordering> arguments specify how this
cmpxchg synchronizes with other atomic operations. Both ordering parameters
must be at least monotonic , the ordering constraint on failure must be no
stronger than that on success, and the failure ordering cannot be either
release or acq_rel ."

The way this operation is implemented in  the standard library of the Rust
programming language, the combination of release (success) and acquire
(failure) is not permitted and will fail at runtime, the prevailing opinion
being, that a failing CAS with release/acquire ordering is actually relaxed
on the store part and hence acquire ordering for the failure case would be
stronger.

However, I don't believe that this a correct reading of the specification
and that neither acquire nor release should be considered stronger or
weaker than the other and that hence that combination should be permitted.

I had hoped to get get some clarification on this issue here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200404/ea502b00/attachment.html>

The LLVM source interprets it as
https://github.com/llvm/llvm-project/blob/a5d375e0cbc4abf6e318270a1bc9c1c0961ae565/llvm/include/llvm/Support/AtomicOrdering.h#L89
.

We should probably drop the requirement; the C++ standard dropped the
corresponding requirement for the library call.  See
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0418r2.html .

-Eli

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Oliver
Giersch via llvm-dev
Sent: Saturday, April 4, 2020 3:59 AM
To: llvm-dev at lists.llvm.org
Subject: [EXT] [llvm-dev] Permitted success/failure orderings for atomic
compare_exchange

A question has come up on how to interpret the wording of LLVM's
documentation regarding the possible memory ordering for success and failure of
atomic compare_exchange operations.

From the LLVM reference:

"The success and failure
ordering<https://llvm.org/docs/LangRef.html#ordering> arguments specify
how this cmpxchg synchronizes with other atomic operations. Both ordering
parameters must be at least monotonic , the ordering constraint on failure must
be no stronger than that on success, and the failure ordering cannot be either
release or acq_rel ."

The way this operation is implemented in  the standard library of the Rust
programming language, the combination of release (success) and acquire (failure)
is not permitted and will fail at runtime, the prevailing opinion being, that a
failing CAS with release/acquire ordering is actually relaxed on the store part
and hence acquire ordering for the failure case would be stronger.

However, I don't believe that this a correct reading of the specification
and that neither acquire nor release should be considered stronger or weaker
than the other and that hence that combination should be permitted.

I had hoped to get get some clarification on this issue here.



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200406/0f7fcb30/attachment.html>

Thanks for the hints, the text of the standards proposal was very
insightful. I am not entirely sure how to interpret the linked source code.
So does the current (previous?) or rather LLVM's current
interpretation/implementation of that standard consider the combination
release on success and acquire on failure to be legal? The table lists both
relationships "release isStrongerThan acquire" and "acquire
isStrongerThan
release" as false. However, the table below it shows the
"isEqualOrStrongerThan" relationship to also be false.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200408/ea28b311/attachment.html>