Some clarification on the SyncRoot pattern: what is the correct way to use this pattern?

Question

I read something about the SyncRoot pattern as a general rule to avoid deadlocks. And reading a question of a few years ago (see this link), I think I understand th

Answer 1

There are a number of concepts here. Firstly what you have implemented correctly is a thread-safe class where no consumers of the class would need to do their own synchronisation. Therefore there is absolutely no need for you to expose the syncRoot object. In the old Collection classes the SyncRoot property was exposed because the classes were not thread-safe.

On locking an arbitrary object and locking your inner collection there is absolutely no difference in terms of correctness or performance of the program. As long as the reference to both does not change they work just as well as parameters to the Monitor.Enter/Exit. Will your inner collection change? If no, mark it as readonly too.

Thirdly there is the comment regarding the use of different locks based on different operations. The classic example of this is the ReaderWriterLock. You should analyse the need to use different levels of locks based on the different functionality exposed by your class.

Answer 2

I would avoid adding a SyncRoot property to the type that I design, here are the reasons:

• Users of my type may need to use different synchronisation mechanism, for example Mutex, or ReaderWriterLock or ReaderWriterLockSlim etc

• The type becomes fatter: its responsibility becomes more scattered. Why would I add support for explicit multithreading locking and no support for other fluff? I would force the user to follow only one practise, which may not be the best solution in all cases

• I would need to implement the property correctly (no returning this or typeof(MyClass)), i.e. this is wrong:

  public object SyncRoot {get {return this;}}
  

I would also avoid using SyncRoot property from the .NET framework types. If I need to make a type w/o SyncRoot property threadsafe I will use one locking pattern, and if a type has this property I will still not opt for locking on SyncRoot. This makes my code style consistent and easier to read/maintain.