C# volatile variable: Memory fences VS. caching

Question

So I researched the topic for quite some time now, and I think I understand the most important concepts like the release and acquire memory fences.

Howe

Answer 1

I read the specs, and they say nothing about whether or not a volatile write will EVER be observed by another thread (volatile read or not). Is that correct or not?

Let me rephrase the question:

Is it correct that the specification says nothing on this matter?

No. The specification is very clear on this matter.

Is a volatile write guaranteed to be observed on another thread?

Yes, if the other thread has a critical execution point. A special side effect is guaranteed to be observed to be ordered with respect to a critical execution point.

A volatile write is a special side effect, and a number of things are critical execution points, including starting and stopping threads. See the spec for a list of such.

Suppose for example thread Alpha sets volatile int field v to one and starts thread Bravo, which reads v, and then joins Bravo. (That is, blocks on Bravo completing.)

At this point we have a special side effect -- the write -- a critical execution point -- the thread start -- and a second special side effect -- a volatile read. Therefore Bravo is required to read one from v. (Assuming no other thread has written it in the meanwhile of course.)

Bravo now increments v to two and ends. That's a special side effect -- a write -- and a critical execution point -- the end of a thread.

When thread Alpha now resumes and does a volatile read of v it is required that it reads two. (Assuming no other thread has written to it in the meanwhile of course.)

The ordering of the side effect of Bravo's write and Bravo's termination must be preserved; plainly Alpha does not run again until after Bravo's termination, and so it is required to observe the write.