search

pat-rogers / Ada-202x-WG9-Informal-Review

This is the place for WG 9 members to submit informal comments on the 202x source document. (This is not the formal ballot that WG 9 will hold later in the process.)
0 stars 0 forks source link

C.6 (19.c/5) "atomic" vs "full access" #163

Open nholsti opened 3 years ago

nholsti commented 3 years ago

This "Implementation Note" follows a rule for full access objects, but does not say anything about full access objects. It seems the sentence that starts "If the record object is atomic then..." should instead start "If the record object is a full access object then...".

ARG-Editor commented 3 years ago

Since there is a such a thing as a volatile full access object, that's insufficient as we do want to talk about the case of atomic reads and writes. So I think we need "... is an atomic full access object then ...". I added this the AARM AI, AI12-0005-1 (as the originating AI is WG 9 approved).

nholsti commented 3 years ago

Of course I don't know what the Note is meant to convey, but it seems to me that the "atomic" part is not the essential point -- the essential point is that full-access-only forbids a write to only a component. Is the Note meant that say that reading or updating a non-atomic full-access object, as a whole, do not have to be atomic?

If so, then I suggest this wording: "... via some sort of store_byte instruction; if the record object is full access then instead a 32-bit read-modify-write must be performed. That read-modify-write need not be atomic, but if the record object is atomic then the read and the write must each separately be atomic."

ARG-Editor commented 3 years ago

The note was written when only atomic objects could be "full access" and thus is only about those. (That's why it said "atomic" and not "full access".) One could write a note that talked about the requirements for non-atomic full access objects, but it would be quite difference since many of the requirements of atomic do not apply to volatile objects.

Note that atomic references need "fences" on most architectures, which are relatively expensive; the reason for allowing volatile full access objects is to eliminate that overhead if it isn't needed for a particular device.

I didn't want to try to write a not about volatile full access objects because the notes in C.6 are notoriously hard to get right, and it is of no help to anyone to write notes that are wrong. So I thought it was too late to construct such a note. (It's also clear to me that no one really thought about what the semantics of volatile full access should be - the feature was constructed assuming everything was atomic and that was changed very late in the process - and I don't want to be inventing that on my own.)