3 ms·

Response from arm: https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/arm-technical-view-on-relaxed-atomics https://communi

by rnrn 3y ago

Response from arm: https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/arm-technical-view-on-relaxed-atomics https://community.arm.com/arm-community-blogs/b/architecture... > The characterization in the post of there being "thousands of bug instances related to relaxed atomics accesses" on Arm systems is unfounded – the comparison is not against the C23 specification, but against an, as yet unadopted, proposed tightening of the specification (specifically Section 2.3 as it is understood that this paper otherwise proposes changes which have been ratified) IMO the “out of thin air” problem is a purely academic limitation of the models and matters not much in reality (since an implementation that generates values out of thin air would be a bit insane - no such hardware exists and no such compiler should either) and therefore it does not make sense to add ordering requirements on relaxed atomics to fix what is a non-issue in practice.

raphlinus 3y ago
Thanks for this, quite useful. There's also more discussion in [1], linked from there, which contains perspective from real memory model experts. I think it's fair to say they're skeptical of the proposal. In particular, they've debunked the SC-DRF claim, which seemed fishy to me, but I didn't want to say anything before gathering more evidence. [1]: https://discourse.llvm.org/t/rfc-strengthen-relaxed-atomics-implementation-behind-mstrict-rlx-atomics-flag/74473 https://discourse.llvm.org/t/rfc-strengthen-relaxed-atomics-...
dataflow 3y ago
> IMO the “out of thin air” problem is a purely academic limitation This article is not about the out of thin air problem, is it? I think you're thinking of something else?
- rnrn 3y ago
  The motivation for the branch after load proposal and the addition of ordering constraints on relaxed atomic discussed in the article is the out of thin air problem See Boehm’s original 2013 proposal (linked in the article) for details
- jcranmer 3y ago
  It's not about out-of-thin-air, but it's relying on other criticisms of out-of-thin-air to motivate why the new model is supposedly better.
- raphlinus 3y ago
  They're related. Requiring sb ∪ rf to be acyclic is indeed one solution to the OOTA problem, but is arguably too heavy a hammer. The other thing to say about OOTA is that it's usually referred to as a purely theoretical problem, but it is possible to imagine compiler optimization that would implicate it, for example using the storage location of the atomic to store a temporary value, knowing that it will be written later in program order anyway. That would be a perfectly reasonable thing to do in sequential code, but obviously a bad idea for atomics. Even so, experience shows that when it comes to letting compiler writers do optimizations that are obviously a bad idea, we have to explicitly and unambiguously forbid it in the spec.

by rnrn 3y ago

raphlinus 3y ago

Thanks for this, quite useful. There's also more discussion in [1], linked from there, which contains perspective from real memory model experts. I think it's fair to say they're skeptical of the proposal. In particular, they've debunked the SC-DRF claim, which seemed fishy to me, but I didn't want to say anything before gathering more evidence. [1]: https://discourse.llvm.org/t/rfc-strengthen-relaxed-atomics-implementation-behind-mstrict-rlx-atomics-flag/74473 https://discourse.llvm.org/t/rfc-strengthen-relaxed-atomics-...

dataflow 3y ago

> IMO the “out of thin air” problem is a purely academic limitation This article is not about the out of thin air problem, is it? I think you're thinking of something else?

rnrn 3y ago
The motivation for the branch after load proposal and the addition of ordering constraints on relaxed atomic discussed in the article is the out of thin air problem See Boehm’s original 2013 proposal (linked in the article) for details
jcranmer 3y ago
It's not about out-of-thin-air, but it's relying on other criticisms of out-of-thin-air to motivate why the new model is supposedly better.
raphlinus 3y ago
They're related. Requiring sb ∪ rf to be acyclic is indeed one solution to the OOTA problem, but is arguably too heavy a hammer. The other thing to say about OOTA is that it's usually referred to as a purely theoretical problem, but it is possible to imagine compiler optimization that would implicate it, for example using the storage location of the atomic to store a temporary value, knowing that it will be written later in program order anyway. That would be a perfectly reasonable thing to do in sequential code, but obviously a bad idea for atomics. Even so, experience shows that when it comes to letting compiler writers do optimizations that are obviously a bad idea, we have to explicitly and unambiguously forbid it in the spec.