Will interlocked operation only prevent other interlocked operation on the same location or any visit to the same location?

Question

when reading
https://msdn.microsoft.com/en-us/magazine/cc163715.aspx , i found the following statement:
interlocked operations guarantee that the update is atomic. This requires the processor to insure that no other processor is also trying to execute an interlocked operation on the same location at the same time.
my question is, what if other thread is trying to read the same location at the same time without using a interlocked operation, will an interlocked operation prevent this?
I was using a readerwriter lock to sync my threads operation on an object. and i found interlocked.compareexchange is handy to initialize the object: interlocked.compareexchange(ref object, FunctionThatReturnAnIntializedObject(),null). However, i am not
sure whether other threads can read that object during the interlocked operation? If they can, how can i prevent them?

Answer 1

"However, i am not sure whether other threads can read that object during the interlocked operation? If they can, how can i prevent them?"
If I understand correctly you're trying to lazy initialize a variable.
Why aren't you using Lazy<T> to begin with, it does exactly what you want if you use LazyThreadSafetyMode.PublicationOnly.
But to answer to your question: mixing interlocked and non-interlocked accesses is problematic. There are a lot of cases where doing this won't work and some cases where it works.
In your particular case this interlocked/non-interlocked mix should work fine. In addition to being atomic .NET's interlocked operations are also supposed to be full fences. A full fence prevents other read/writes from being moved before/after the interlocked
operation and that's exactly what you need to prevent the writes required to initialize the object from being moved after interlocked.
If the thread that doesn't use interlocked to read the object variable gets a non-null reference then it means that the initialization of the object was done, otherwise it couldn't have got a non-null reference in the first place.
There is a small chance to run into a problem caused by compiler optimizations. If the thread that doesn't use interlocked has a loop like the following then it's possible that the loop will never end.
while (object == null) { ... }
That's because in the absence of volatile and interlocked the compiler can read "object" into a register before the loop. The loop test will keep comparing the register value with null and the loop will never end. Such a situation is rather unlikely
but you should make the object variable volatile to avoid this.