Locking horror: Am I going mad?
-
In a new body of code I've "inherited" there is a lot of code that looks something like this (simplified somewhat):
public class A
{
private ArrayList list = new ArrayList();
private object m_lock = new object();public A()
{
lock(m_lock)
{
list.Add("MyString");
}
}
}Now am I going mad? That lock statement to my eye is marginally pointless. Is there ever any justification for locking on a non static, private object in a constructor? Cheers, E.
-
In a new body of code I've "inherited" there is a lot of code that looks something like this (simplified somewhat):
public class A
{
private ArrayList list = new ArrayList();
private object m_lock = new object();public A()
{
lock(m_lock)
{
list.Add("MyString");
}
}
}Now am I going mad? That lock statement to my eye is marginally pointless. Is there ever any justification for locking on a non static, private object in a constructor? Cheers, E.
Probably not, and why have a separate object for the lock either (in the included code anyway)? But it could be worse as well.
-
In a new body of code I've "inherited" there is a lot of code that looks something like this (simplified somewhat):
public class A
{
private ArrayList list = new ArrayList();
private object m_lock = new object();public A()
{
lock(m_lock)
{
list.Add("MyString");
}
}
}Now am I going mad? That lock statement to my eye is marginally pointless. Is there ever any justification for locking on a non static, private object in a constructor? Cheers, E.
The previous position of the developer was in jeweller’s shop. :-D
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
In a new body of code I've "inherited" there is a lot of code that looks something like this (simplified somewhat):
public class A
{
private ArrayList list = new ArrayList();
private object m_lock = new object();public A()
{
lock(m_lock)
{
list.Add("MyString");
}
}
}Now am I going mad? That lock statement to my eye is marginally pointless. Is there ever any justification for locking on a non static, private object in a constructor? Cheers, E.
The bottom-most MSDN example for the lock statement actually looks quite similar: http://msdn.microsoft.com/en-us/library/c5kehkcz(VS.80).aspx[^] Regards, Dust Signs
-
The bottom-most MSDN example for the lock statement actually looks quite similar: http://msdn.microsoft.com/en-us/library/c5kehkcz(VS.80).aspx[^] Regards, Dust Signs
Yet not at all the same.
-
Probably not, and why have a separate object for the lock either (in the included code anyway)? But it could be worse as well.
[I'll get there, just give me a sec. :D] From a coding perspective, people often use 'this' as the object to lock on, but that is not a preferred method of locking. The reason is that code outside of the class might want to use that object to lock on as well, there by possibly causing a deadlock. So, the recommendation is to often use internal private objects to do this. Now, in this case, I would assume the array list would be the best item to lock on. But out of readability or perhaps if that array list is reinitialized later, they may have opted for a separate unchanging object reference for the lock to prevent any kind of concurrency issues. So, in short, the lock in the constructor is needless, but the object used in the lock very well could be needed depending on the implementation of the class.
-
In a new body of code I've "inherited" there is a lot of code that looks something like this (simplified somewhat):
public class A
{
private ArrayList list = new ArrayList();
private object m_lock = new object();public A()
{
lock(m_lock)
{
list.Add("MyString");
}
}
}Now am I going mad? That lock statement to my eye is marginally pointless. Is there ever any justification for locking on a non static, private object in a constructor? Cheers, E.
