Support acquire and release

[jfbastien]

The spec currently only supports sequentially-consistent atomic accesses. C++ also has acquire and release, which are key to obtaining good performance on a variety of weak memory systems (see optimizations possible).

The main pushback was on undefined behavior: JavaScript is coming from a world where the only nondeterminisms are NaN bits, endianness, timers, and transcendentals. Looking at C++ is daunting because UB leads to full nasal demons. It's necessary to enforce security of the user from random web pages, but there's a strong worry that developers will also get bit by e.g. testing on x86 and then having their site fail on mobile. Acquire and release can be misused, but they don't lead to more nondeterminism that the limited nondeterminism intended for JavaScript's atomic (in fact, it's sequentially consistent for data-race free programs!).

I'm quite comfortable with this as long as we offer good tooling, e.g. asan and tsan should work (a WebAssembly goal).

Note that acquire and release aren't as contended as relaxed (which has "out of thin air" issues), and consume is entirely unimplemented (besides ad-hoc agreements with GCC e.g. with RCU).

[hboehm]

I think the main cost of adding acquire/release is added complexity in the specification. As far as I can tell, we would no longer be able to avoid talking about cache coherence (essentially sequential consistency for an individual variable).

The usage model is also appreciably more complicated, but only if you actually use acquire/release atomics. I don't think that any new form of undefined behavior is introduced.

For better or worse, I'm not sure that testing on the wrong architecture is that much of an issue. Even if you test on ARM, my experience is that the failure probabilities due to memory ordering issues (or many other kinds of race issues) are so low, you probably still won't catch the problem during testing. And that issue already exists for ordinary data accesses with sequentially consistent atomics.

[lars-t-hansen]

FWIW, the original spec had a discussion where we iterated to some kind of understanding about naming for acq/rel atomics, so that we could be confident that we could add them later.

I feel fairly strongly that trying to get acq/rel into atomics v1 is going to significantly increase resistance (within the committee) to the entire feature, since the feature already adds quite a bit of complexity to JS, and new kinds of complexity at that. (Obviously I don't mind talking about the details, but I'm going to keep them out of the proposal.)

[jfbastien]

I'd be interested in at least posing the question to TC39: we plan to add acq/rel at some point, it has advantages (details...), do you want it in v1 or later?

TC39's new "staged" proposal process, and their overall support of the SIMD authors, leads me to believe that a stage 2 or stage 3 proposal could add acq/rel.

[lars-t-hansen]

I believe a stage 2 proposal could add it. That gives us a few months to hash out the details.

[lars-t-hansen]

So obviously we did not add this for the initial proposal. At this stage, I'm content to let wasm drive the need for additional memory orders, and to force their introduction into JS when that seems necessary.