Possible Duplicate:
Difference between lock(locker) and lock(variable_which_I_am_using)
In all of the "thread-safe" code examples i've seen, they lock on a separate dummy object. Why cant locks be directly performed on the data in question?
Asked
Active
Viewed 3,292 times
23
-
great question, this was my first thought too. – Russell Dec 09 '09 at 11:54
-
4In the interests of helping people to best find the answer they are looking for this question should not be closed. @Bill, the so-called exact duplicate question is awkwardly titled and worded and does not clearly state the fundamental question unlike this question. I believe this question is much more likely to attract attention in searches. Threfore I have voted to re-open. – Ash Dec 12 '09 at 05:45
3 Answers
20
Locking on a separate private dummy object gives you a guarantee that no one else is locking in that object.
If you lock on the data and that same piece of data is visible to the outside you lose that guarantee. For example:
public class MyObject
{
public void SharedMethod()
{
lock (this)
{
// Do stuff
}
}
}
class Program
{
static void Main(string[] args)
{
MyObject o = new MyObject();
lock (o)
{
new Thread(() =>
{
// Gets blocked 2s because of external lock
o.SharedMethod();
}).Start();
Thread.Sleep(2000);
}
}
}
João Angelo
- 56,552
- 12
- 145
- 147
-
I think i get it. If you have a separate dummy object then by locking on an object you want to use you're not preventing it from doing anything? – RCIX Dec 10 '09 at 02:12
-
I mean, when you try to call a method on that object that needs to clock something. – RCIX Dec 10 '09 at 02:13
-
1Yes, the main advantage in locking on private dummy objects is that you know that only your code will lock on those objects and that way no external code will affect your internal synchronization mechanisms. – João Angelo Dec 10 '09 at 10:44
10
Jeff Richter (author of CLR Via C#) explains why in this article on Safe Thread Synchronization.
Specifically, in that article the section "Why the Great Idea isn't So Great" answers your question.
It's actually a chapter from the book CLR Via C#.
In summary, having a private object as the "synclock" object allows your class to encapsulate and control any locking your class needs. Therefore regardless of how many clients use your class, locking is performed consistently and correctly.
-
+1. I was going to point out his book, but this article is effectively the same! – RichardOD Dec 09 '09 at 11:22
-
If an object needs to be locked during certain operations, and if outside code may need to have two or more operations be performed without the lock being released between them, the object must either expose the lock or methods to acquire and release it. Exposing neither will simply make it impossible for external code to properly do what it needs to do. – supercat May 06 '14 at 18:06
