SyncRoots virtually useless, may change /w generics?

I never found much use for SyncRoots, especially in data structures. Their usefulness always had a direct inverse ratio to the complexity of the concurrency/locking requirements. Wasn't worth mentioning because I always assumed that it was just me who doesn't grok it, but it is nice to know that others agree. Also interesting to note the teaser that some of that might change in Whidbey...

Via [BradA]:

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.