C#

NotPrivateClass x=new NotPrivateClass();<br />
lock(x)

//this = x<br />
lock (this) { ... }

Colin Angus Mackay wrote:

this could potentially lead to a deadlock.

public class PublicClass1
{
   public PublicClass1(){};
   public void LockMe1(PublicClass2 aPublicInstance2)
   {
     lock(this) // ref line (X)
     {
         lock(aPublicInstance2)
         {
            MessageBox.ShowDialog("no deadlock, great!!");
         }
     }
}

public class PublicClass2
{
   public PublicClass2(){};
}

// aPublicInstance2 is an object of PublicClass2
// aPublicInstance1 is an object of PublicClass1
lock(aPublicInstance2) // ref line (Y)
{
   lock(aPublicInstance1)
   {
       MessageBox.ShowDialog("no deadlock, great!!");
   }
}

aPublicInstance1.LockMe1(aPublicInstance2); // aPublicInstancex is the same object as in thread Y

Colin Angus Mackay wrote:

If that happens, I'd imagine that it becomes easier to get into a situation where deadlocks can occur.

George_George wrote:

Why using internal private object as lock object will reduce chance of deadlock compared with using this object? Could you describe a scenario please?

George_George wrote:

I think you metn the "list" object is the synchronising object

George_George wrote:

But what do you mean "the object you are protecting with the lock", you mean also the list obejct which we are going to make it thread-safe?