Why is this an issue?
Locking on a class field synchronizes not on the field itself, but on the object assigned to it. Thus, there are some good practices to follow to
avoid bugs related to thread synchronization.
- Locking on a non-
readonly field makes it possible for the field’s value to change while a thread is in the code block locked on
the old value. This allows another thread to lock on the new value and access the same block concurrently.
- Locking on a new instance of an object undermines synchronization because two different threads running the same method in parallel will lock
on different instances of the same object, allowing them to access the synchronized block at the same time.
- Locking on a string literal is also dangerous since, depending on whether the string is interned or not, different threads may or may not
synchronize on the same object instance.
Noncompliant code example
private Color color = new Color("red");
private readonly string colorString = "red";
private void DoSomething()
{
// Synchronizing access via "color"
lock (color) // Noncompliant; lock is actually on object instance "red" referred to by the "color" field
{
//...
color = new Color("green"); // other threads now allowed into this block
// ...
}
lock (new object()) // Noncompliant; this is a no-op
{
// ...
}
lock (colorString) // Noncompliant; strings can be interned
{
// ...
}
}
Compliant solution
private Color color = new Color("red");
private readonly object lockObj = new object();
private void DoSomething()
{
lock (lockObj)
{
//...
color = new Color("green");
// ...
}
}
Resources
