CODEWITHSUNDEEP
c#multithreading
gsb
gsb

Reputation: 1229

Lock on an object that might change during code execution

Let's suppose I have a thread that locks on an object reference

Thread #1 

lock(myObj) { ... }

later in code I have myObj = new XYZObj();

and then Thread #2 locks on it

lock(myObj) { ... }

Will this code be thread safe, if the object reference has changed? When the object reference changes, the first lock is still valid?

Upvotes: 6

Views: 3767

Answers (3)

Johann Gerell
Johann Gerell

Reputation: 25591

Will this code be thread safe

The statement lock(myObj) { ... } is only safe until a new object reference is assigned to the myObj variable. Addition: Also, it's only safe if any data shared between threads that is used non-atomically mutating inside a lock on an object is only used non-atomically mutating inside locks on that same object.

So, every time you enter a lock for myObj, the actual referenced object is what is being used for the lock, not your variable. If you change the variable to reference a new object, then you're effectively locking different objects in different locks, which obviously isn't what you wanted. But, then again, the next time you come back to the first lock, the first and second lock object might be in sync again, and so it'll be safe again. Maybe!

As you can see, that behavior is completely broken. Is this a hypothetical question or are you really doing like that?

Upvotes: 2

SLaks
SLaks

Reputation: 888185

Locks work on instances, not variables.
The lock statement will hold its own reference to the instance so that it will only exit the instance you entered.

The spec says:

where x is an expression of a reference-type, is precisely equivalent to

System.Threading.Monitor.Enter(x);
try {
   ...
}
finally {
   System.Threading.Monitor.Exit(x);
}

except that x is only evaluated once.

If you re-assign the variable between the two locks, you will get two valid locks on two different instances.

In general, however, you should never do that; it's a recipe for subtle bugs and race conditions.
You should only lock on dedicated readonly lock objects.

Upvotes: 9

Mongus Pong
Mongus Pong

Reputation: 11477

No. They will both be locking on different objects.

According to MSDN

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

Upvotes: 4

Related Questions