Atomic semantics

[littledan]

From GetValueFromBuffer and SetValueInBuffer:

Let accessAtomic be true if isTypedArray is true and type is "Int8", "Uint8", "Int16", "Uint16", "Int32", or "Uint32", otherwise false

What is the motivation for these semantics? Is it documented anywhere? Are TypedArrays always aligned in reasonable implementations with respect to their underlying element size, or could this result in atomics that cross a word boundary?

[lars-t-hansen]

The motivation is that modern memory systems work this way, for good reason: It means that if you can limit the raciness of your program (usually through type discipline that ensures that you don't access a cell as part of both an N-byte access and an M-byte access) then you can count on the written data not tearing. This is essential when your language allows races, has pointers, and needs to be safe. (Java is the obvious example.) This does not remove the race, but it exposes a capability that all hardware we care about has. The feature is motivated by providing the ability to compile at least some languages of that class to JS or asm.js, which I think is valuable.

Is it documented anywhere? Issue #71 had a (sub)discussion pertaining to this, IIRC because @pizlonator brought it up in Issue #77. It had come up before -- it was part of the initial SAB design but was taken out after pushback (I don't mean to single out Nick Bray but I remember him being opposed). With hindsight I now read the pushback as "we'd much rather have relaxed atomics than this", but that's a different discussion. I put it back in because @pizlonator was questioning the absence and I had wanted it all along. It creates a small amount of complication in the spec but I don't think this is where we blow our complexity budget.

About alignment: I can slice this a couple of ways. One way is to observe that the atomic operations will need to apply to exactly the same elements that we're talking about here, and will generally require alignment on non-x86 platforms. Int32 and Uint32 atomics are additionally required to be lock-free, and that forces the implementation's hand in this regard: Int32Array will normally have to be aligned on a four-byte boundary, and that forces alignment for two-byte accesses as well. Another way is to observe that for performance, implementations will want to do aligned loads and stores on architectures where unaligned accesses are expensive (probably all of them) or illegal (some of them). This forces proper alignment in reasonable implementations.

I suppose in the limit an implementation on x86 does not have to align the memory properly since the LOCK prefix works on unaligned accesses, but ever since the Core-2 Duo the hardware is single-copy atomic for up to eight-byte accesses anyway (see MACHINES.md), so the SAB spec does not restrict even such an implementation (which I think is probably an unreasonable implementation).

Edit 7/19: s/word/byte/ in two places.

[lars-t-hansen]

I added a section to DISCUSSION.md summarizing anything from above not already covered. (Not sure it belongs there but there it is.)

[littledan]

Thanks for this explanation.