Getting a lock using an object, rather than this - Threading

Question

I’m trying to learn threading in C#, and I’ve seen something crop up in few articles but I am not sure I fully understand it: In the given two examples, what would the fundamental difference between getting a lock on ‘this’ vs ‘thisLock’.

Example 1:

class Account
    {
        decimal balance;
        private Object thisLock = new Object();

        public void Withdraw(decimal amount)
        {
            lock (thisLock)
            {
                if (amount > balance)
                {
                    throw new Exception("Insufficient funds");
                }
                balance -= amount;
            }
        }
    }

Example 2:

class Account
    {
        decimal balance;

        public void Withdraw(decimal amount)
        {
            lock (this)
            {
                if (amount > balance)
                {
                    throw new Exception("Insufficient funds");
                }
                balance -= amount;
            }
        }
    }

From my understanding, I would of thought that ‘thisLock’ only stops other threads from entering that specific area of code.

Were as getting a lock on ‘this’ would stop all operations on the object, i.e. calls to other methods by other threads?

Have I fundamentally miss understood this, or is that the correct conclusion?

Does [this](http://stackoverflow.com/questions/251391/why-is-lockthis-bad) helps? — Sriram Sakthivel, Dec 03 '13 at 13:22
Sriram's suggestion is the answer -- to be clear, `lock(this)` is in no way different than `lock(somethingElse)` when seen in isolation. — Jon, Dec 03 '13 at 13:23

score 2 · Answer 1 · answered Dec 03 '13 at 13:22

2

Both cases will have the exact same effect. One difference is that other objects cannot see thisLock, so you can be sure nothing else will reuse the lock. If you lock on this, another part of code can also lock on the same instance of Account.

answered Dec 03 '13 at 13:22

viraptor

33,322
10
107
191

_"you can be sure nothing else will reuse the lock"_ - as long as no other method in that class uses the same lock object. – CodeCaster Dec 03 '13 at 13:30
@CodeCaster: Of course, but this is something you -as writer of that class- have full control over :-) – Steven Dec 03 '13 at 13:31

score 1 · Answer 2 · answered Dec 03 '13 at 15:06

The difference is locking granularity.

When locking an object, (simplified) a bit is set on the instance. Anyone else trying to lock the same instance will end up in a wait state until the lock is released by the other.

In many cases, methods on a object can be used at the same time (i.o.w. In parallel). Locking the entire object (this) would exclude the usage of any other method if that method also uses 'lock(this)'.

Since lock can be used on any reference type, we can create "lock" objects. Where we implement the 'lock(lockObject)' on a exclusion basis.

As example;

MethodA1 and MethodA2 cannot be used at the same time
MethodB1 and MethodB2 cannot be used at the same time
MethodA1/2 can be used at the same time as MethodB1/2.

If we would use the lock(this) on every method, we would also be exluding MethodA1/2 from running at the same time as MethodB1/2.

By creating 2 lock objects (lockAMethods, lockBMethods) we can now implement our locking more granular.

In MethodA1 and MethodA2 we'll use "lock(lockAMethods)" to make sure the A1 and A2 methods cannot run at the same time.
In MethodB1 and B2 we'll use the "lock(lockBMethods)" to make sure the B1 and B2 methods cannot run at the same time.

We can however lock(lockAMethods) and lock(lockBMethods) at the same time. Hence we can now run MethodA1/2 at the same time as MethodB1/2.

Hope this helps,

score 0 · Answer 3 · edited May 23 '17 at 11:49

0

You stated

From my understanding, I would of thought that ‘thisLock’ only stops other threads from entering that specific area of code.
Were as getting a lock on ‘this’ would stop all operations on the object, i.e. calls to other methods by other threads?

Whether you use lock(this) or lock(thisLock) in both the statements, it will only stops other threads from entering that specific area of code.
But as a general practice it is always advised not to use lock(this) rather create another object and place a lock on that object.

EDIT yes as Sriram Sakthivel has commented, he is absolutely right, please read Why is lock(this) {...} bad? for more information why we should avoid lock(this)

edited May 23 '17 at 11:49

Community

1
1

answered Dec 03 '13 at 13:23

Deepak Bhatia

6,230
2
24
58

2

The advice to not to use `lock(this)` must be placed in perspective. The Framework Design Guidelines advice against this, because it is bad from a framework perspective. A consumer of your framework can always take a lock on an instance of a type in your framework, which could accidentally lead to a deadlock. When writing a LOB application, there is full control over which code is written and this might not be such a big problem. I would say that in that case `lock(this)` is fine, but using a lock on an instance of another type is actually bad practice. – Steven Dec 03 '13 at 13:30
1

Fixed the bad link, you linked current question's link :) – Sriram Sakthivel Dec 03 '13 at 13:30

Getting a lock using an object, rather than this - Threading

3 Answers3