3

After I finish reading the article, "Atomicity, volatility and immutability are different, part three", written by Eric Lippert, I come up with a question that even if I put a lock around a reference type variable, but what if the cpu once gets its hand on the variable stored in the main memory and loads the variable into its register page and read the variable only from its register since, assuming the volatile keyword is not applied to this variable. So the change made to this variable on other threads cannot be seen by this thread.

I am not sure if my logic is correct here. From the article, it indicates there is no need to declare a field as volatile if there is a lock around it. Could anyone please explain to me what exactly happen if the code use a lock to control the access to the variable.

ORZ__
  • 31
  • 2
  • 1
    I think [Memory Barrier](http://stackoverflow.com/questions/2844452/memory-barrier-by-lock-statement) answers cover your concerns. If not clarify what other information is needed so post can be re-opened. – Alexei Levenkov Oct 07 '15 at 01:41
  • 1
    The tl;dr of that article is that most all lock implementations include memory barriers. As long as you use locks on do your synchronization (rather than writing your own locks or other concurrency primitives), you should be fine in terms of memory synchronization. – Brian Malehorn Oct 07 '15 at 03:11
  • 2
    @AlexeiLevenkov Thank you for your comment. It really helps me understand this topic. Actually the link you post remind me of an article, "Memory Models Understand the Impact of Low-Lock Techniques in Multithreaded Apps" on the Oct. 2005 issue of MSDN magazine. I read it again and it clears some of my questions. And for others who have the same question, besides the article above, [Memory barriers force cache coherency?](http://stackoverflow.com/questions/30958375/memory-barriers-force-cache-coherency), this can help clarify the cache issue – ORZ__ Oct 07 '15 at 06:04
  • 3
    The correct conclusion to reach here is not "locks introduce memory barriers, therefore I get the latest value of the field when I access it consistently under locks". The correct conclusion to reach is **the C# language specification guarantees that locks will produce that behaviour regardless of whether they do so using memory barriers or some other technique**. Remember, memory barriers are implementation details of particular CPUs. – Eric Lippert Oct 07 '15 at 16:54
  • 1
    @EricLippert You are the man! That's very illuminating. If you dont mind me asking, do you have a book or any source in mind that I can study this topic in a more systematic way? Stackoverflow is an amazing website, but it is more like a patch than a whole thing. Thanks in advance. :) – ORZ__ Oct 08 '15 at 00:35
  • 1
    @orz__ Try Joe Duffys book. You're welcome! – Eric Lippert Oct 08 '15 at 00:44
  • 1
    @EricLippert Thanks a lot! you just open a new door to me. I have great interest in learning and writing concurrent program. I love C#, but someday I think I will move to C/C++, ;) – ORZ__ Oct 08 '15 at 00:59
  • 1
    @ORZ__: C# In A Nutshell also has some good stuff on threading. – Eric Lippert Oct 08 '15 at 11:45
  • 1
    @EricLippert C# in A Nutshell actually is the first book I use to learn C#. I read it twice. And I always keep it within my reach, along with C++ Primer Plus and a couple books about python and R, lol. I read the threading chapter back and forth, but it only touches the surface. It is a good introduction to multithreading programming, tho. – ORZ__ Oct 08 '15 at 21:56

0 Answers0