Hashtables have a syncroot property but generic dictionaries dont. If i have code that does this:
lock (hashtable.Syncroot) { .... }
How i do i replicate this if i am removing the hashtable and changing to generic dictionaries.
Hashtables have a syncroot property but generic dictionaries dont. If i have code that does this:
lock (hashtable.Syncroot) { .... }
How i do i replicate this if i am removing the hashtable and changing to generic dictionaries.
var dictionary = new Dictionary<int, string>();
lock(((ICollection) dictionary).SyncRoot)
{
// ...
}
If the hashtable/dictionary isn't public, you could just lock the dictionary object itself.
The new thinking behind SyncRoot is that it was a mistake in the original design. If the only thing to lock is the dictionary and it's private, you can lock it or another object that serves as the synchronization object. The latter technique is useful when the state you are protecting is more than just the dictionary.
// used as you would have used SyncRoot before
object _syncLock = new object();
Dictionary<string, int> numberMapper = new Dictionary<string, int>();
// in some method...
lock (_syncLock)
{
// use the dictionary here.
}
If you are going strictly for compatability then Bryan is correct. This is the best way to maintain your current semantics on top of a Dictionary.
Expanding on it though. The reason the SyncRoot property was not directly added to the generic dictionary is that it's a dangerous way to do synchronization. It's only slighly better than "lock(this)" which is very dangerous and prone to deadlocks. Here are a couple of links that speak to why this is bad.
Here is a threadsafe generic dictionary implementation
http://devplanet.com/blogs/brianr/archive/2008/09/26/thread-safe-dictionary-in-net.aspx