The overview currently notes that accesses to shared globals are not allowed to tear. The rationale behind this decision was that the spec does not currently treat numeric globals as sequences of bytes, so it has no way to describe tearing. Lacking data, we also assumed the performance overhead of preventing tearing on shared globals would be acceptable.
We didn't consider, however, that the same spec problem comes up for accesses to numeric fields of shared structs. It seems unlikely that the overhead of disallowing tears on struct fields will be acceptable, so we might have to start treating them as sequences of bytes after all. We might as well then do the same for globals.
The overview currently notes that accesses to shared globals are not allowed to tear. The rationale behind this decision was that the spec does not currently treat numeric globals as sequences of bytes, so it has no way to describe tearing. Lacking data, we also assumed the performance overhead of preventing tearing on shared globals would be acceptable.
We didn't consider, however, that the same spec problem comes up for accesses to numeric fields of shared structs. It seems unlikely that the overhead of disallowing tears on struct fields will be acceptable, so we might have to start treating them as sequences of bytes after all. We might as well then do the same for globals.