Questionable value of SyncRoot on Collections
You’ll notice a SyncRoot property on
many of the Collections in System.Collections. 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:
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
ICollection.
Rest assured we will not make the
same mistake as we build the generic versions of these
collections.