I know we need to take care of thread safety for static member variables inside the class. Do we need to worry about the instance member variables?
Share
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.
I know we need to take care of thread safety for static member variables inside the class. Do we need to worry about the instance member variables?
It depends on whether you want your type to be thread-safe… and what you mean by that.
Most of the time I think it’s entirely reasonable to document that the type isn’t thread-safe, but can be used safely from different threads with appropriate synchronization. Most .NET types fall into this category.
That would you can usually make sure that only “coordinating” objects need to worry about synchronization, rather than putting a lock in every method and property – a strategy which is painful, and doesn’t really address the wider synchronization issues you’re likely to run into anyway.
Of course, types which will naturally be used from multiple threads – ones specifically design to enable concurrency, or service locators etc, should be thread-safe – and be documented so. Likewise fully immutable types are naturally thread-safe to start with.
Finally, there’s the matter of what counts as “thread-safe” to start with. You should read Eric Lippert’s blog post on the matter to clarify what sort of thing you should be thinking about and documenting.