I’m trying to understand the point of the syncroot in ICollection. Why not just lock the collection?
lock(myCollection)
{
//do stuff to myCollection
}
vs
lock(myCollection.SyncRoot)
{
//do stuff to myCollection
}
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Typically, if thread safety is a serious concern, I would avoid either of these options.
A far better option is typically to maintain your own private variable, and lock on it in all methods where it’s required – including the entire public API that accesses the collection.
The real danger is that, by locking on a type that’s exposed or could be exposed to the outside world, you potentially open up the ability for the “outside world” to mess with your synchronization. If more than one lock is being used, this can lead to dead locks (if the outside locks on something you aren’t expecting).
By creating a private variable, and locking exclusively on it, you’re “taking control” of the situation. This makes it much more clear what is occurring. In addition, it eases synchronization between multiple objects, especially later as you maintain the code, since the lock is very clear.