Questionable value of SyncRoot on Collections

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">You’ll notice a SyncRoot property on
many of the Collections in System.Collections. style="mso-spacerun: yes">  In retrospeced, I think this property
was a mistake.  Krzysztof Cwalina, a
Program Manger on my team,  just sent me some thoughts on why that is – I
agree with him: "urn:schemas-microsoft-com:office:office" />

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 

style="FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: Verdana">We found the
SyncRoot-based synchronization APIs to be insufficiently flexible for most
scenarios. The APIs allow for thread safe access to a single member of a
collection. The problem is that there are numerous scenarios where you need to
lock on multiple operations (for example remove one item and add another). In
other words, it’s usually the code that uses a collection that wants to choose
(and can actually implement) the right synchronization policy, not the
collection itself. We found that SyncRoot is actually used very rarely and in
cases where it is used, it actually does not add much value. In cases where it’s
not used, it is just an annoyance to implementers of

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Rest assured we will not make the
same mistake as we build the generic versions of these

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 


Comments (7)

  1. Marco Russo says:

    Are you talking about the IsSynchronized property of ICollection?

  2. I have found SyncRoot to be very useful foundation for building thread-safe behavior. When using a Synchronized collection wrapper, I know that individual methods will lock as necessary (and the collection type has the knowledge of which methods should be locking). I can also lock on SyncRoot to hold a lock over multiple calls, enforcing a "broader" synchronization policy in my application code. This is all good. I’m curious about what you might be considering as a replacement. If SyncRoot wasn’t supported, how could I guarantee that other users of the collection won’t write to the collection while I’m enumerating it? I realize that an alternative is to trap the exception that results when the collection has changed since the start of the enumeration, but restarting the enumeration seems clumsy. I value the encapsulation of the locking semantics within the collection itself. I can see alternatives to SyncRoot, such as the collections exposing an interface to perform locking…this would add value in allowing the collection implementor to define the locking mechanism (instead of just providing an object for Monitor.Enter). I would think, though, that it would be very important to continue to provide a common, well-known synchronization point such as SyncRoot.

  3. Ian Ringrose says:

    What I would find useful is.
    ReadOnly() that returns a object that only provides methods to read the collection but points at the collection so gets any update I make.

    It would also be nice to have an event when an item is added to a collection, so as to make it easier to implement object models that have a lot of collections of child objects that need ‘back pointers’ set when they are added to there parent collection. There may be a better way of solving this problem, I hope so, just give it to us.

  4. Thanks for all the comments on my recent post. I have one more that I’ll do in the next couple of weeks,…