Atomicity of variable references - 64-bit values

[yaakov-h]

In section 9.6, the spec states:

Reads and writes of other types, including long, ulong, double, and decimal, as well as user-defined types, need not be atomic.

I assume this part of the spec still comes from the days of 32-bit machines and runtimes.

long, ulong, and double are all 64-bit value types. (I don't remember what decimal is.)

Could these be non-atomic even on a 64-bit runtime?

[333fred]

Up to the runtime. As the specification says, the C# language makes no assumptions about it.

[yaakov-h]

Do you know if the common runtimes (e.g. Framework, Core) have a spec that covers this behaviour beyond the C# minimum requirements?

[koszeggy]

As the specification says, the C# language makes no assumptions about it.

In fact, some core types such as ConcurrentDictionary has very specific assumtions about it (see the comment that refers to ECMA-335).

Could these be non-atomic even on a 64-bit runtime?

Based on these we can quite confidently say that accessing 64-bit values (long, ulong, double and 64-bit enums) is atomic on a 64-bit runtime on every platform.

[333fred]

In fact, some core types such as ConcurrentDictionary has very specific assumtions about it (see the comment that refers to ECMA-335).

Yes, concurrent dictionary and plenty of other code assumes that it is running on a specific runtime, which gives stronger guarantees than C# does.

[333fred]

Do you know if the common runtimes (e.g. Framework, Core) have a spec that covers this behaviour beyond the C# minimum requirements?

That would be ECMA-335.

[yaakov-h]

Thanks.

[alexrp]

Ecma 335, §I.12.6.6 states:

A conforming CLI shall guarantee that read and write access to properly aligned memory
locations no larger than the native word size (the size of type native int) is atomic
(see §I.12.6.2) when all the write accesses to a location are the same size. Atomic writes shall
alter no bits other than those written. Unless explicit layout control (see
Partition II (Controlling Instance Layout)) is used to alter the default behavior, data elements no
larger than the natural word size (the size of a native int) shall be properly aligned. Object
references shall be treated as though they are stored in the native word size.

[Note: There is no guarantee about atomic update (read-modify-write) of memory, except for
methods provided for that purpose as part of the class library (see Partition IV). An atomic write
of a “small data item” (an item no larger than the native word size) is required to do an atomic
read/modify/write on hardware that does not support direct writes to small data items. end note]

[Note: There is no guaranteed atomic access to 8-byte data when the size of a native int is
32 bits even though some implementations might perform atomic operations when the data is
aligned on an 8-byte boundary. end note]

There's probably an argument to be made that the C# spec ought to be updated to reflect these rules. I'm not aware of any real hardware in use today where these guarantees don't exist. Further, somewhat worryingly, the C# spec doesn't seem to mention the alignment requirements, which means the CLI rules are not actually a superset of the C# rules.

[yaakov-h]

Oh that's interesting. So this bit of the spec seems to confirm what I was looking for (that Unsafe.SizeOf<T>() <= IntPtr.Size should be atomic), but since the C# spec doesn't make any alignment guarantees, everything could go out the window if its not explicitly one of the types that the C# spec requires to be atomic?

[alexrp]

that Unsafe.SizeOf<T>() <= IntPtr.Size should be atomic

As long as you're not doing anything weird with alignment, yes.

This is one way to obtain a misaligned int, for example:

[StructLayout(LayoutKind.Sequential, Pack = 1)]
struct Foo
{
    byte B; // offset 0x0
    int I; // offset 0x1, not properly aligned
}

void Bar(ref Foo foo)
{
    int i = foo.I; // You cannot expect this to be an atomic load.
}

everything could go out the window if its not explicitly one of the types that the C# spec requires to be atomic?

Yes, but also, it all goes out the window anyway. C# requires e.g. int to always be atomic, no exceptions. But as pointed out above, that's simply not the reality that any runtime implements due to hardware alignment requirements. A misaligned int will not be atomic, no matter how much the C# spec wants it to be so.

Note that this is entirely a theoretical problem with the C# spec. In practice, Roslyn follows the Ecma 335 rules. It's safe to ignore what the C# spec says about atomicity until it's brought in line with Ecma 335, §I.12.6.6.

[tannergooding]

Oh that's interesting. So this bit of the spec seems to confirm what I was looking for (that Unsafe.SizeOf() <= IntPtr.Size should be atomic), but since the C# spec doesn't make any alignment guarantees, everything could go out the window if its not explicitly one of the types that the C# spec requires to be atomic?

Its a bit more complex than that. It must also be a "single value" and therefore its really restricted to bool, char, byte, sbyte, short, ushort, int, uint, nint, nuint, and float on 32-bit Systems. On 64-bit systems it also extends to long, ulong, and double. This may extend to simple wrapper types such as struct S { byte x; }. It would not apply to types like struct S { byte x; byte y; } even though its 2-bytes. It would not apply to some struct S { ushort x; byte y; } even though 3 <= sizeof(nint).

This distinction is important because read/writes are only "well-defined" for primitive types. Once you have a user-defined struct, what appears to be a single read/write may actually be many read/writes. The same applies to long, ulong, and double on 32-bit platforms (it could be one read/write, it could be many read/writes).

[yaakov-h]

What about Nullable<>? Is that considered a user defined struct?

[tannergooding]

It has two fields, a bool and a T and so there is no guarantee updating it is atomic, even when T is a primitive.