Why is CopyDataBlockBytes atomic?

[jfbastien]

CopyDataBlockBytes is effectively the same as memcpy, but it's specified as atomic when writing to / from a SAB.

Why?

This means that each byte access is sequentially consistent. That's quite a big hammer. Do we expect developers to rely on this property, or would it be sufficient to copy non-atomically, and expect developers to fence before / after CopyDataBlockBytes?

Or maybe CopyDataBlockBytes should imply a seq_cst fence before / after, but not inside the copy operation? That would still make it possible to e.g. vectorize CopyDataBlockBytes in circumstances where that's faster.

[jfbastien]

Same question for CreateSharedByteDataBlock: is the fact that WriteSharedMemory(db, i, true, 1, 0) is atomic even observable? It's called before the db is even returned.

[lars-t-hansen]

I don't understand what you're talking about. Are you confused about the meaning of ReadSharedMemory and WriteSharedMemory?

ReadSharedMemory and WriteSharedMemory are not atomic. They are just the semantic subroutines used to access shared memory. They provide guarantees about access-atomicity under appropriate conditions but ordering constraints in the sense of sequential consistency are provided outside these routines.

[jfbastien]

Reading the spec, it's unclear if CopyDataBlockBytes can be a simple copy loop (such as memcpy). They're invoked with IIUC the "atomic" parameter set, which leads me to believe the simple copy loop is invalid.

[lars-t-hansen]

Ah! For single-byte accesses that flag should not matter, but it's misleading for it to be true. I will fix that.

[lars-t-hansen]

I will add a NOTE to ReadSharedMemory and WriteSharedMemory to clarify further:

"The parameter accessAtomic requests that the access be non-tearing if other conditions for such an access are met (as detailed below); the parameter has no bearing on the ordering of accesses to memory."

[jfbastien]

Ah! Gotcha. I thought the flag meant both no-tearing as well as seq_cst.