Provide a guaranteed-lock-free type?

[lars-t-hansen]

In Issue #7 @jfbastien writes:

From C++ atomic_flag with methods test_and_set and clear says:

Operations on an object of type atomic_flag shall be lock-free. [ Note: Hence the operations should also be address-free. No other type requires lock-free operations, so the atomic_flag type is the minimum hardware-implemented type needed to conform to this International standard. The remaining types can be emulated with atomic_flag, though with less than ideal properties. — end note ]

It may be worth having a similar parallel in SAB. We could require that SAB's atomic_flag be given a 4-byte location and the underlying test_and_set and clear will only touch the bits that the hardware can guarantee as lock-free.

[lars-t-hansen]

In Issue #77, @pizlonator expressed a preference for guaranteed four-byte lock-free access (probably int32, in practice, uint32 being a bit awkward for JS).

[jfbastien]

I think 32-bit values are likely to work on all the HW we target. C++ is overly cautious with atomic_flag by not specifying the size and leaving it up to the implementation to choose the right size for the target. We don't have this leisure of choosing the size once we know the target: we can teach LLVM that 32-bit is wasm's size for atomic_flag but that's it.

[sunfishcode]

fwiw, WebAssembly also expects to support a guaranteed 4-byte lock-free access (as well as an 8-byte lock-free access in 64-bit mode).

[lars-t-hansen]

OK. +1 from me. Proposed spec changes:

• In the shmem spec, in the section for isLockFree, if n=4 then the implementation always returns true
• In the agents spec the [[IsLockFree4]] property on the Agents Record is removed with a note added that 4-byte values are always lock free

In reference to my earlier remark above, this would be independent of whether the access type is int32 or uint32, since the atomic operation would only be expressed on a machine word anyhow; any pre/post conversion is immaterial.

@binji, opinions?

[binji]

sgtm, it's hard for me to imagine an architecture that supports SABs where this wouldn't be true.

[lars-t-hansen]

Specs changed and published.