Add reference to .NET Memory Model

[agocke]

All code should preserve the guarantees of the .NET memory model, therefore this should be in the list.

[tannergooding]

Should we have a sub-bullet for "language specific memory model additions"?

i.e. C# (abstract language) has its own memory model that is disconnected from .NET, then Roslyn (specific implementation of the language targeting .NET) has potential addendums to the language. So safe C# code also needs to respect any such stipulations or variants in there.

The same would apply to safe F# targeting other safe F#, etc.

We can't really easily define the bounds for interlanguage interop (i.e. C# calling F# or vice versa), but I think we could call out that within a single language and we expect languages to at least be compatible with the .NET memory model

[jkotas]

This doc explains the expected behavior of memory access (in the presence of multithreading). I am not sure what it means for the .NET code to be valid with respect to the properties explained in this doc. I think the most immediate interpretation of this statement would be that we want to guarantee race conditions free code, but that's not what we are doing here.

[jkotas]

Alternative proposals - add the following towards the end of "Global invariants" chapter:

These properties interact with other .NET runtime behaviors, such as .NET Memory Model. For example, it is invalid for safe code to be able to trigger undefined behavior caused by misaligned memory accesses.

[agocke]

The linked doc explains the guaranteed behaviors of managed code. These are properties that must be maintained by all unsafe code. For example, the doc says:

Managed references are always aligned to their size on the given platform and accesses are atomic.

If unsafe code is used to create a managed reference that is either unaligned or where access is not atomic, that would be invalid code and the unsafe code would be in error.

[jkotas]

Managed references are always aligned to their size on the given platform and accesses are atomic.

This talks about the alignment of storage for the managed reference. It does not talk about the location where the managed reference points to. For example, situation like this:

[StructLayout(LayoutKind.Explicit)]
ref struct S
{
    [FieldOffset(1)]
    ref byte x;
}

This is invalid type layout. The runtime will refuse to load this type, unsafe code won't help you to get around that.