Question: It looks like the **mono** implementation has no `MemoryBarrier` calls inside the `ReaderWriterLockSlim` methods. So when I make any changes inside a `write lock`, I can receive old cached values in another thread which uses a `read lock`.

Is it really possible? Should I insert `MemoryBarrier` before and after the code inside Read and Write lock?

Answer: 
Looking at (what I think is) [the mono source](https://github.com/mosa/Mono-Class-Libraries/blob/master/mcs/class/System.Core/System.Threading/ReaderWriterLockSlim.cs), the **Mono** `ReaderWriterLockSlim` is implemented using `Interlocked` calls. 

These calls [include a memory barrier on x86](https://stackoverflow.com/questions/1581718/does-interlocked-compareexchange-use-a-memory-barrier), so you shouldn't need to add one.
As Peter correctly points out, the implementation does introduce a memory barrier, just not explicitly.

More generally: the C# language specification requires that certain side effects be well ordered with respect to locks. Though that rule only applies to locks entered with the C# `lock` statement, it would be exceedingly strange for a provider of a custom locking primitive to make a locking object that did not follow the same rules. You are wise to double-check, but in general you can assume that if its a threading primitive then it has been designed to ensure that important side effects are well-ordered around it.