Make locations exclusively atomic or non-atomic?

[lars-t-hansen]

[A discussion thread copied from the original spec document, moved here because the discussion picked up again.]

JF Bastien / 10:54 PM Mar 4:

I think we're missing a requirement that atomic locations always be accessed through this Atomics object. Note that destruction ends the object's lifetime, but until that occurs each typed location must only be accessed through the Atomics object of the right type.

What happens if the user breaks this requirement? In C++ that's UB.

jyasskin / 12:03 AM Mar 5:

This being Javascript, we can't "require" that users do anything correctly. We'll just need to define the behavior of an atomic/non-atomc race, in a similar way to a non-atomic/non-atomic race.

Lars Hansen / 4:34 PM Mar 5:

Yeah, I think there may be a misunderstanding about the level of the API here. This facility provides no atomic objects a la C++ or Java, only typed locations in shared memory with both atomic and non-atomic operations on those locations. Those locations can be aliased too. A requirement for atomicity which is stated here and there in this document is that operations on the same address are all atomic and all of the same size. There is no enforcement of that requirement and I hope none is implied anywhere.

jyasskin / 5:05 PM Mar 5:

Btw, I had a similar problem in designing http://llvm.org/docs/LangRef.html#memory-model-for-concurrent-operations, since LLVM doesn't have typed memory either. That model isn't quite right, since it misses that if two 4-byte atomic writes conflict, a 4-byte read of the same memory won't see part of each. But you still might find some useful inspiration in it.
Show less

JF Bastien / 6:37 PM Mar 5:

I'm thinking about the optimizations that are allowed to occur on accesses to SABs (atomic and non-atomic). I think that we may be overconstraining them without this guarantee that memory locations are either always accessed atomically or never accessed atomically during an "object's" lifetime.

Lars Hansen / 1:45 PM Jul 3:

There should be no such constraint implied by the spec. All I'm claiming is that for the atomicity of an access to be guaranteed it must only "race" (for the lack of a better word) with other accesses that are also atomic, to the same address, and of the same access size.

Olivier Giroux / 6:36 PM Aug 22:

I would like to echo JF's concern but appeal to a more abstract argument.

In http://wg21.link/n4136, Mark Batty showed that that if you don't have type safety together with your memory model, then the current dominant technique for specifying memory models allows for weird bugs (e.g.: impossibly constrains implementations). Those weird bugs are in C11 but not in C++11, or Java (presumably).

I see a note below that you want to appeal to JSR-133 for your memory model. You may break it. Also, JSR-133 is a major challenge just to comprehend in the first place, so the repercussions may be hard to scope.

[lars-t-hansen]

Olivier, thanks for the link; I'll study that paper and come back to this issue when I've done so.

[lars-t-hansen]

OK, to sum up: With disjoint atomic and non-atomic locations there exists a proof that DRF C++11 programs using no low-level atomics are SC (Batty's previous paper), summarized in N4136. Adding the possibility to reference atomic cells also with non-atomic accesses breaks that proof, and Batty attempts (section 5 of N4136) to fix that breakage by tweaking the read-from rule for non-atomic accesses, concluding in the end that the tweaks don't work. The conclusion seems to be that the axiomatic style of the C++11 memory model isn't quite right for the job and both N4136 and later work (eg Pichon-Pharabod and Sewell, POPL 2016) are making stabs at an operational model to more cleanly specify what the compiler and hardware can and will do.

That is certainly something to be aware of when writing up the memory model for this proposal. We can't hope to separate atomics and non-atomics in memory (because we're creating a compilation target for C) and given the many reasonable examples Batty gives of why one would need to account for non-atomic accesses to atomic locations it does not make sense to simply outlaw non-atomic accesses to atomic locations. JS is a slightly easier compilation target than C, certainly at present (no relaxed or release-acquire atomics, and no cross-thread compiler optimizations), but I don't know how much that will buy us yet.