Atomics and memory model specification questions/issues

[anba]

24.4.1.3 GetWaiterList

• The term "semantic object" is not defined.
• The "store of WaiterList objects" and the lookup/retrieval operations could be more explicitly defined, e.g. similar to the Map.prototype methods.

24.4.*

• The term "semantic function" is not defined.
• The various operations should work on number values instead of list of byte values, e.g. the result of add when called with « 255 » and « 255 » is currently somewhat ambiguous, because the element type is not given which means i.a. that the length of the returned list of byte values isn't specified.
• Also: It probably wouldn't hurt to have an explicit definition of the term "byte value".

27.7.3 Tear Free Reads

• Has "See Access Atomicity below.", but there's no "Access Atomicity" in the following paragraphs. Can we simply remove this reference and should it point to another section?

[jmdyck]

re "semantic object": Probably a different term should be used. (Elsewhere, "specification type value" is used, but it's kind of clunky.)

At first glance, it seems like a WaiterList could be modelled as just a List. But apparently it also has a 'critical section' (which is never defined, by the way), so perhaps it would be better modelled as a Record with 2 fields.

[jmdyck]

re "semantic function": I think this just means a function in the mathematical sense. The 'Algorithm Conventions' clause uses the term "mathematical function" for this. The RegExp clause uses the term "internal procedure" for something similar.

Alternatively, I think you could argue that the things referred to as "semantic functions" qualify as "abstract operations".

[lars-t-hansen]

Related background: https://github.com/tc39/ecmascript_sharedmem/issues/118 https://github.com/tc39/ecmascript_sharedmem/issues/120

I have no clear memory of where "semantic function" came from, but ISTR it is the result of an earlier bikeshed aimed at ensuring that there was no confusion between these functions and ES functions, at the time when the higher-order operation was introduced (the original spec draft just spelled out the algorithms individually). Any term will suffice as long as that confusion is avoided.

(SIMD has the same concern, presumably.)

[lars-t-hansen]

The critical section is orthogonal to the list, it just needs to be clear that the critical section protects that list. The list can be any data structure, since it's only accessed inside the critical section.

What a "Critical Section" is was never defined because, like addition, it is supposed to be a well understood abstraction. Obviously I could have been wrong about that, but at this point I expect there's 60 years of usage of the term backing it. (Not meaning to be snide, just factual.)

[jmdyck]

(Note that 60 years of usage doesn't exempt a term from definition: the spec even defines 'context-free grammar'!)

Anyway, while I more-or-less understand what a critical section is, it's not clear to me how one comes to be associated with a list of agents. For me, it would make sense to read "the critical section of an algorithm or process" but not "the critical section for a data structure".

[syg]

@anba Regarding the reference to "Access Atomicity" in 27.7.3 Tear Free Reads, it is a stale note from the SAB draft referencing an informative section that was not merged into the final draft. I'll file an editorial PR to remove.

[syg]

@anba I don't understand the point about using numbers and list of bytes values. The list-of-bytes abstraction is to interface with the event semantics of the memory model. Is the confusion here the same as the "semantic function" one, i.e., the exact semantics of the add semantic function acting on two lists-of-bytes?

[anba]

The issue is that the conversion from list of bytes -> Number value -> list of bytes isn't sufficiently specified because the result after applying the operation can exceed the input type's domain as demonstrated for the input « 255 ».

I'd prefer to add [[ElementType]] to ReadModifyWriteSharedMemory and to change 27.5.4 ComposeWriteEventBytes, step 3.d.iii as follows:

1. Let isLittleEndian be the value of the [[LittleEndian]] field of the surrounding agent's Agent Record.
2. Let bytesNum be RawBytesToNumber(W.[[ElementType]], bytesRead, isLittleEndian).
3. Let payloadNum be RawBytesToNumber(W.[[ElementType]], W.[[Payload]], isLittleEndian).
4. Let result be W.[[ModifyOp]](bytesNum, payloadNum).
5. Let bytesModified be NumberToRawBytes(W.[[ElementType]], result, isLittleEndian).

And then update the various semantic functions for Atomics.* to operate on Number values.

[syg]

I see, so explicitly spelling out the prose "applies the addition operation to the Number values corresponding to the List of byte values arguments and returns a List of byte values corresponding to the result of that operation" and clarifies overflow.

That is a-ok with me.

[anba]

and clarifies overflow.

For overflow but also in general to select the correct length of the returned List of byte values (I forgot to mention this aspect in my last comment). For example the Number value 0 could be encoded as « 0 » or « 0, 0 » or « 0, 0, 0, 0 », so we need to define the type of the semantic function as (List[N], List[N]) → List[N]. Or switch to using Number values as proposed above.

[ljharb]

@syg @anba are there still action items here, or can this be closed?

[ExE-Boss]

@ljharb WaiterList still uses semantic objects, I’m fixing that in https://github.com/tc39/ecma262/pull/2240.