Thread safe property access

[NN---]

Is there any guarantee that property access always reads the field from memory ?

E.g. this code from .NET.

internal bool Disposed => _disposed != 0;

My assumption that JIT can optimize the property access into a variable access or into register and then the processor might cache its value.

[PathogenDavid]

I don't believe properties do anything special here.

If you need this guarantee you should mark _disposed as volatile to indicate to the JIT that it shouldn't make any optimizations that assume single-threaded access.

[acaly]

You might be aware of this, but I still want to point out that volatile by itself doesn't guarantee thread-safety. You'll have to use either a lock or an atomic RMW operation (c# has an Interlocked class). Those are obviously more than an auto-property should handle.

[acaly]

I know it's different from volatile in C++, but no, volatile by itself usually isn't thread safe.

A read of a volatile field ... it is guaranteed to occur prior to any references to memory that occur after it in the instruction sequence
A write of a volatile field ... it is guaranteed to happen after any memory references prior to the write instruction in the instruction sequence

These are basically talking about ordering within one single thread. When there are multiple threads, all reads might happen earlier and all writes might happen later, and the thread might be preempted by OS or runtime GC.

Note that the simplest spin lock in C++ uses not only the std::atomic_flag (a volatile bool), but also the atomic_flag::test_and_set (an atomic RMW operation). C++ has std::atomic<T>::load and std::atomic<T>::store, which accept std::memory_order, including the acquire and release semantics (with the same power of C# volatiles), but still, test_and_set is necessary to implement a lock. (The underlying principle is the consensus number).

I can imagine 2 uses of the _disposed flag:

1. Check the flag and dispose the object if it's not set yet.
2. Check the flag and access its content if it's not set.

In both cases, the volatile read cannot protect the object from being disposed by other threads.

[acaly]

You can confirm that in C#, a volatile read on a int isn't really different from a normal read from generated code.

[gfoidl]

You can confirm that in C#, a volatile read on a int isn't really different from a normal read from

Sharplab shows the codgen for x86/x64, and they have a strong memory model.
On ARM -- which has a weak memory model -- the JIT (not C# compiler Roslyn) takes this into account and generates different code from normal reads/writes. It's only on strong memory models, where the "volatile evaporates".

[acaly]

they have a strong memory model

I understand that. Still, this stronger memory model isn't enough for thread safety. Why do you think we still have RMW and locks on x86/x64 platforms?

[gfoidl]

To note: my reply was just for the quoted text (which is correct, but not in general, hence the addendum for it).

Thread safety / atomicity is one "thing", the other one is visibility.
For the latter memory models come into play.
For the first only read / writes with word-size are atomic, all other read / writes need to be done with special treatment, like Interlocked (asm on x86: lock cmpxchg so at the cpu-level + full memory barrier) or by exclusive access to the shared ressource like monitors, etc. where the runtime also guarantees a memory barrier, so that the change gets "visible".

So volatile is for visibility, and has per se nothing to do with atomicity.
(That current .NET uses Interlocked for some implementations of Volatile is an implemenation detail and hence atomicity is a side-effect).

[danmoseley]

Also answered by @gfoidl and @PathogenDavid