Question

When some thread locks myList in SomeMethodA and while executing the block inside lock, does other thread can execute myList.Add(1) in SomeMethodB or it will wait because ‘myList’ is locked in SomeMethodA?

class A
{
    private List<int> myList;

    public void SomeMethodA()
    {
       lock(myList)
       {
          //...
       }
    }

    public void SomeMethodB()
    {
       myList.Add(1);
    }
}

Answer 1

Edit Explicit answer: No, you need to lock the list explicitely in the SomeMethodB. The compiler will not automatically add locks for you

• why would you ever have to explicitely lock otherwise?
• things would be horribly slow. It would be far better to just forbid multi threading than to always lock each object access¹

The recommended idiom is this:

class A
{
    private List<int> myList;
    private readonly object _lockObject = new Object();

    public void SomeMethodA()
    {
       lock(_lockObject)
       {
          //...
       }
    }

    public void SomeMethodB()
    {
       lock(_lockObject)
       {
           myList.Add(1);
       }
    }
}

Beware of exposing finegrained locking like that (you’d typically want to do coarsegrained locking as long as no blocking operations can occur under the lock).

Note Locks in C# are reentrant, though, so calling SomeMethodB from within the lock in SomeMethodA will not deadlock

Update Rationale behind using a private lock object instance:

In general, avoid locking on a public type, or instances beyond your code’s control. The common constructs lock (this), lock (typeof (MyType)), and lock (“myLock”) violate this guideline:

• lock (this) is a problem if the instance can be accessed publicly.
• lock (typeof (MyType)) is a problem if MyType is publicly accessible.
• lock("myLock") is a problem because any other code in the process using the same string, will share the same lock.

Best practice is to define a private object to lock on, or a private static object variable to protect data common to all instances.

See: http://msdn.microsoft.com/en-us/library/c5kehkcz.aspx

---

¹ (aside from other issues with that approach, such as null values, reference updates, deadlocks etc.)