Does locking ensure reads and writes are flushed from caches? If so, how?

Question

I was reading this MSDN article on lockless thread syncing. The article seems to infer that as long as you enter a lock before accessing shared variables, then those variables will be up to date (in .Net 2.0 at least).

I got to thinking how this was possible? A lock in .Net is just some arbitrary object that all threads check before accessing memory, but the lock itself has no knowledge of the memory locations that are being accessed.

If I have a thread updating a variable, or even a whole chunk of memory, How are those updates guaranteed to be flushed from CPU caches when entering / exiting a lock? Are ALL memory accesses effectively made volatile inside the lock?

Answer 1

Check the work of Eric Lippert: http://blogs.msdn.com/b/ericlippert/archive/2011/06/16/atomicity-volatility-and-immutability-are-different-part-three.aspx

Locks guarantee that memory read or modified inside the lock is observed to be consistent, locks guarantee that only one thread accesses a given hunk of memory at a time, and so on.

So yes, as long as you lock each time before accessing shared resources, you can be pretty sure its up to date

EDIT look up the following post for more information and a very usefull overview: http://igoro.com/archive/volatile-keyword-in-c-memory-model-explained/

Answer 2

Well, the article explains it:

1. Reads cannot move before entering a lock.

2. Writes cannot move after exiting a lock.

And more explanation from the same article:

When a thread exits the lock, the third rule ensures that any writes made while the lock was held are visible to all processors. Before the memory is accessed by another thread, the reading thread will enter a lock and the second rule ensures that the reads happen logically after the lock was taken.

Answer 3

Not all c# memory reads and writes are volatile, no. (imagine if that was the case performance-wise!)

But.

How are those updates guaranteed to be flushed from CPU caches when entering / exiting a lock

CPU caches are CPU specific, however they all have some form of memory coherence protocol. That is to say, when you access some memory from a core, if it is present in another core cache, the protocol the CPU uses will ensure that the data gets delivered to the local core.

What Petar Ivanov alludes to in his answer is however very relevant. You should check out memory consistency model if you want to understand more what his point is.

Now, how C# guarantees that the memory is up-to-date is up to the C# implementers, and Eric Lippert's blog is certainly a good place to understand the underlying issues.