title: Few confusing things about locks
body: <p>I know how to use locks in my app, but there still few things that I don't quite understand about locking ( BTW - I know that the lock statement is just a shorthand notation for working with Monitor class type ).</p>
  
  <p>From <a href="http://msdn.microsoft.com/en-us/library/ms173179.aspx" rel="nofollow noreferrer">http://msdn.microsoft.com/en-us/library/ms173179.aspx</a>:</p>
  
  <pre><code> public class TestThreading
   {
       private System.Object lockThis = new System.Object();
  
       public void Function()
       {
  
           lock (lockThis)
           {
              // Access thread-sensitive resources.
           }
       }
    }
  </code></pre>
  
  <blockquote>
    <p>The argument provided to the lock keyword must be an object based on a reference 
    type, and is used to define the scope of the lock. In the example above, the lock scope is limited to this function because no references to the object lockThis exist outside the function. If such a reference did exist, lock scope would extend to that object. </p>
  </blockquote>
  
  <p>a) I don’t understand how lockThis object defines the scope of the lock. Scope of the lock is all the  code between <strong><em>lock(lockThis){</em></strong> and adjacent <strong><em>}</em></strong>, so what exactly is it meant by <em>“lock scope would extend to that object”</em>?</p>
  
  <p>b) What does the term <em>locking on object lockThis</em>  mean? Simply that we use a reference to lockThis to lock a region of code? Thus, the term doesn't suggest that we locked lockThis object?</p>
  
  <p>thanx</p>
  
  <p><br></p>
  
  <p>Replying to David Morton:</p>
  
  <p>I apologize if my reply is a bit long winded, but I couldn't think of any other way to word my questions and still be somewhat coherent:  </p>
  
  <blockquote>
    <ol>
    <li>The scope of the lock, in this situation, is the individual instance of the class itself. This is opposed to crossing all instance of the specific class. You could have your lock cross all instances TestThreading by making lockThis static. That's what's meant by the "scope" of the lock: whether it's applicable to a single instance, or applicable to every instance of a particular type. </li>
    </ol>
    
    <p>Other objects could still access lockThis from another thread, but they wouldn't be able to process code that is surrounded by a lock on that object.</p>
  </blockquote>
  
  <p>If we call the code surrounded by lock ( located inside <em>TestThreading.Function</em> ) <strong>C</strong>, then since <em>TestThreading.Function</em> is not static, each <em>TestThreading</em> instance has its own copy of <strong>C</strong>. But if <em>TestThreading.Function</em> was static, then all <em>TestThreading</em> instances would share the same copy of <strong>C</strong>. As an analogy, if <strong>C</strong> is a room and if <em>TestThreading.Function</em> is not static, then each <em>TestThreading</em> instance would have its own <strong>C room</strong>, but if function was static, then all <em>TestThreading</em> instances would share the same <strong>C room</strong>. </p>
  
  <p>Following that analogy, I interpret <em>lockThis</em> as a key to <strong>room C</strong>. If <em>lockThis</em> is static and if <em>TestThreading.Function</em> is not static, then  all <em>TestThreading</em> instances would use same key to enter their own <strong>C rooms</strong>. </p>
  
  <ul>
  <li><p>Thus, I don’t see any significance in <em>lockThis</em> being static or not, since in either case each <em>TestThreading</em> instance will use <em>lockThis</em> to enter its own <em>room C</em> ( assuming TestThreading.Function is not static ). Thus, following that logic, shouldn't the scope of the lock always be individual instance of the class (assuming TestThreading.Function is not static )?</p></li>
  <li><p>Similarly, I don’t see any significance in <em>lockThis</em> being private or public, since again <em>TestThreading</em> instance will use <em>lockThis</em> to enter its own <strong>room C</strong>( assuming <em>TestThreading.Function</em> is not static)</p></li>
  </ul>
  
  <p><br></p>
  
  <p>Second reply to David Morton</p>
  
  <blockquote>
    <p>In response to your response: There is a significance. If TestThreading.Function is static, then lockThis has to be static, otherwise, TestThreading.Function cannot access lockThis at all. </p>
  </blockquote>
  
  <p>I’m not sure what you mean by <em>TestThreading.Function</em> not being able to access <em>lockThis</em>?! Again assume we call the code surrounded by lock ( located inside <em>TestThreading.Function</em> ) <strong>C</strong>.
  If <em>TestThreading.Function</em> is static and thus there is only one room, but <em>lockThis</em> is non-static, and if we have the following definition:</p>
  
  <pre><code> public class TestThreading
   {
      private System.Object lockThis = new System.Object();
  
      public static  void Function()
      {
  
          lock (new TestThreading().lockThis)
          {
             // Access thread-sensitive resources.
          }
      }
   }
  </code></pre>
  
  <p>,then whenever some thread would access <strong>room C</strong>, it would use a new key. Thus, if 100 threads accessed <strong>room C</strong>, then same room would be opened using 100 different keys?! So the code does work, it just doesn’t make much sense, since there would be no synchronization at all between threads?! </p>
  
  <blockquote>
    <p>The scope of the lock, in this situation, is the individual instance of the class itself. This is opposed to crossing all instance of the specific class. You could have your lock cross all instances TestThreading by making lockThis static.</p>
  </blockquote>
  
  <p>I was confused with the term <em>scope of the lock</em>, since I’ve interpret it as: if the <em>lockThis</em> was static, then all <em>TestThread</em> instances would share the same room (aka lock), even though <em>TestThread.Function</em> isn’t static. Assuming I understand it correctly now,  then  the term lock is referring to the key (thus lock doesn’t refer to the room?! ) used for opening the doors? </p>
  
  <p>As such,  if we assume that <em>lockThis</em> is static and <em>TestThread.Function</em> is not static, then the scope of the key/lock is all <em>TestThread</em> instances, which  means that all <em>TestThread</em> instances share the same key and thus when one <em>TestThread</em> instance opens the door to its room using this key, the other instances won’t be able to open the doors to their rooms until first instance releases that key? </p>
  
  <p><br></p>
  
  <p>Third reply to David Morton</p>
  
  <blockquote>
    <p>No, if Function is static, then all TestThread instances would share the same room, if lockThis is static, then all TestThread instances would share the same key.</p>
  </blockquote>
  
  <p>Do you agree that the word <em>lock</em> used in a sentence <em>scope of the lock</em> at least in a way refers to the key ( key being <em>lockThis</em> instance )? </p>
  
  <blockquote>
    <p>The room is the code that is executed within the lock, not the lockThis object itself, that's simply the key.</p>
  </blockquote>
  
  <p>[Defense mode ON] That’s  what I’ve said in my last reply. ;) [Defense mode OFF]</p>