5

I have this code in a class:

private static MyObject _locker = new MyObject();

...

lock (_locker)
{
     ...
     _locker = new MyObject();
     ...
}

Will it keep the lock on _locker ?

Theodore Zographos
  • 2,215
  • 1
  • 24
  • 23

3 Answers3

8

No, it will not. From the C# specification (emphasis is mine):

A lock statement of the form lock (x) ... 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.

Since x is not reevaluated the lock will be released.

João Angelo
  • 56,552
  • 12
  • 145
  • 147
2

Don't do this. Consider using a separate object entirely to hold the state of the lock, not necessarily the object you want to protect in the lock statement. I often write code (ok, not often) like this:

private static readonly object _locker = new object();
private static MyObject _object;
...

lock (_locker)
{
     ...
     _object = new MyObject();
     ...
}

It involves a completely different sort of program flow than what you're looking at. lock() defines a critical section in the code -- you don't use it as an all-purpose thread safety mechanism for any type of object (which is what I think your intent is in your code?)

Dave Markle
  • 95,573
  • 20
  • 147
  • 170
2

I assume it will keep the lock on the MyObject instance that was set to _locker when lock has been called, i.e. it will keep the lock on the original instance of _locker, not on the newly created MyObject instance. In the following code, the lock will be kept on MyObject("OriginalInstance") when the lock is called for the first time. When it is called the second time, it will lock on MyObject("NewInstance").

private static MyObject _locker = new MyObject("OriginalInstance");

...

lock (_locker)
{
    ...
    _locker = new MyObject("NewInstance");
    ...
}

Therefore, the next thread may enter the critical section without problems because the new instance is not locked.

Anyway, doing stuff like this is generally considered bad practice. See MSDN for some advices on how to use lock.

gehho
  • 9,049
  • 3
  • 45
  • 59