What is the current memory model guarantees made by the CLR?

[jasonmalinowski]

Recently while looking at some code, there was some lock-free code not using volatile or any other sort of synchronization primitive. The code was potentially unsafe if the CLR was allowed to reorder writes where the initialization of an instance could be reordered after the write of the instance pointer to a field. Or more concretely, if somebody writes:

this._myObject = new MyObject(arg1, arg2, arg3); // the constructor just assigns these arguments to fields

is it possible to observe _myObject being written to on a different thread, while the writes inside constructor won't be observed yet.

I'm having troubles finding documentation on what's actually guaranteed today. #4906 discussed it a bit and observed that .NET 2.0 (non-Core)-era blog posts made stronger guarantees than the ECMA spec; but then @jkotas's comment here implied that maybe those things don't hold for ARM. I recall hearing once that the ARM runtimes did some extra trickery for some common patterns (double-checked locking, etc.) but I don't actually know anything concrete.

Do we actually document what guarantees are being made, or just as importantly, what isn't being guaranteed?

@sharwell noted that the C# compiler's support for caching lambdas does not cache in a volatile field, which makes us think that either there's some special handling for that case, or generally there's a guarantee being made when you create an object in the runtime that any writes of that object's state can't be reordered after the constructor's completion.

[stephentoub]

I opened #63474 about documenting the memory model.

is it possible to observe _myObject being written to on a different thread, while the writes inside constructor won't be observed yet.

According to the ECMA memory model, yes. As an undocumented implementation detail of coreclr / mono, no: writes to fields of a reference type incur a store release barrier.