Lock-free guarantees for 8- and 16-bit atomics

[binji]

There is some discussion on the LLVM issue list about lock-free guarantees: https://bugs.llvm.org/show_bug.cgi?id=33146

This was previously discussed a long time ago here: WebAssembly/design#300

Should we guarantee that 8-bit and 16-bit atomics are lock-free?

[lars-t-hansen]

It seems silly to do this if the reason is that LLVM does not have the internal structures to represent the WebAssembly semantics.

I also note that it is possible to move to lock-freedom later if we don't spec that now, but much less simple to move to non-lock-freedom if we prematurely spec lock-freedom now...

Finally, one principle we've had for wasm atomics has been to stay compatible with JS, which does not guarantee lock-freedom for 8-bit and 16-bit data at this time. If we do move to lock-free 8-bit and 16-bit atomics for wasm now i'd really like to see a commitment from somebody to push that through TC39. Won't be a lot of work but should be done. Effectively a wasm lock-free requirement imposes that on the SAB implementation in any browser, which in turn means JS in all those browsers will have lock-free atomics whether ES specs that or not.

(Personally I'd prefer to spend our cycles on other topics than this until we have a threading MVP.)

[lars-t-hansen]

All that said (and counter to what is asserted in the May meeting text), I did conclude some time ago that ARM, MIPS, POWER, and x86 are all fine: tc39/proposal-ecmascript-sharedmem#10 (comment). For ES there was the question of very early ARMv6, and of course the corner cases that may exist (WebAssembly/design#300 (comment)), but I'm unconcerned about those in the context of wasm.

[binji]

Sorry, there was a lot of discussion about this topic, and I was having a hard time finding a resolution. Thanks for the pointers to these!

[binji]

We agreed in the CG meeting to not mention lock freedom in the WebAssembly spec (at least not in a normative way). The idea is to provide atomic accesses for 8, 16, 32, and 64 bit sizes. We don't say how the implementation will make them atomic -- it may use an atomic instruction or an implicit lock.