We Keep Coding

How to lock dictionary then safely hand off lock to a value in the dictionary?

I am trying to find a safe approach for synchronizing access to a nested dictionary where operations on the outer dictionary lock any manipulation to the entire collection. However, once the inner dictionary is retrieved I would like to release the outer lock and only prevent threads from manipulating the inner dictionary.
It is trivial to use the lock keyword for this once the inner dictionary exists within the outer dictionary, however, I am struggling to find a safe approach for adding and populating the inner dictionary without introducing a race condition. Assume "Populating" the inner dictionary will be an expensive operation. This is why doing it under lock for the outer dictionary is not an option. Other threads must have access to the outer dictionary to perform operations on OTHER inner dictionaries while "populate" is executed against the new inner dictionary.
I have included examples below which better illustrate my question.
A trivial approach which I believe introduces a race condition
An approach I believe will work, however, can result in unnecessarily populating multiple inner dictionaries. This will only end up using the first inner dictionary which wins the race.
An approach I believe will work, however, it is unfamiliar territory. Even with extensive testing I would be concerned that my lack of experience using the C#'s Monitor object could lead to unexpected consequences.
Example 1: What I believe to be an unsafe approach to my problem. However, this is how I traditionally synchronization. I would prefer to use this approach, however I do not know of a way to use the lock keyword and achieve the behavior I need.
public void SyncronizationExample1(Dictionary<TKey, Dictionary<TKey2, ReferenceTypedValues>> outerDictionary, TKey newKey)
{
Dictionary<TKey2, ReferenceTypedValues> innerDictionary = null;
lock (outerDictionary)
{
// No need to add a new innerDictionary, it already exists
if (outerDictionary.ContainsKey(newKey))
{
return;
}
innerDictionary = new Dictionary<TKey2, ReferenceTypedValues>();
outerDictionary.Add(newKey, innerDictionary);
}
// I want to allow other threads to have access to outerDictionary
// However, I don't want other threads working against THIS innerDictionary
lock (innerDictionary)
{
// Here lies my concern with this approach. Another thread could have
// taken the lock for innerDictionary. Doing this all under the lock
// for outerDictionary would be safe but would prevent access to other
// inner dictionaries while expensive operations are performed only
// pertaining to THIS innerDictionary
this.PopulateInnerDictionary(innerDictionary);
}
}
Example 2: An approach using lock that does not encounter the issues portrayed in Example 1. However, not ideal as unnecessary computation may occur if multiple threads attempt the operation at the same time. Note that this approach could be modified to lock against a global "Populate" lock, however, that would prevent multiple threads from concurrently populating different innerDictionaries.
public void SyncronizationExample3(Dictionary<TKey, Dictionary<TKey2, ReferenceTypedValues>> outerDictionary, TKey newKey)
{
lock (outerDictionary)
{
if (outerDictionary.ContainsKey(newKey))
{
// No need to add a new innerDictionary, it already exists
return;
}
}
var innerDictionary = new Dictionary<TKey2, ReferenceTypedValues>();
// Expensive operation - if called by multiple threads at the same time
// multiple innerDictionaries will be populated but only the one to win
// the race will be utilized.
this.PopulateInnerDictionary(innerDictionary);
lock (this.outerDictionary)
{
if (!outerDictionary.ContainsKey(newKey))
{
// If another thread won the race this newKey would be in outerDictionary
// The innerDictionary we just populated is redundant
outerDictionary.Add(newKey, innerDictionary);
}
}
}
Example 3: What I believe to be a solution to the potential synchronization issues demonstrated in Example 1. However, I am unfamiliar with using the Monitor pattern and would greatly appreciate feedback.
public void SyncronizationExample3(Dictionary<TKey, Dictionary<TKey2, ReferenceTypedValues>> outerDictionary, TKey newKey)
{
Dictionary<TKey2, ReferenceTypedValues> innerDictionary = null;
bool aquiredLockForOuterDictionary = false;
bool aquiredLockForInnerDictionary = false;
try
{
Monitor.Enter(outerDictionary, ref aquiredLockForOuterDictionary);
if (outerDictionary.Contains(newKey)
{
// No need to add a new innerDictionary, it already exists
return;
}
innerDictionary = new Dictionary<TKey2, ReferenceTypedValues>();
outerDictionary.Add(newKey, innerDictionary);
// This is where I "handoff" the lock to innerDictionary to alleviate my concern
// in Example 1 where another thread could steal the innerDictionary lock
Monitor.Enter(innerDictionary, ref aquiredLockForInnerDictionary);
}
finally
{
// I read that this bool pattern was preferred for .net 4+,
// however I am unsure if this is the best practice
if (aquiredLockForOuterDictionary)
{
Monitor.Exit(dictionary);
}
}
try
{
if (!aquiredLockForInnerDictionary)
{
// An exception must have occurred prior to or during the acquisition
// of this lock. Not sure how I'd handle this yet but
// I'm pretty shit out of luck.
return;
}
// Here I would perform an expensive operation against the innerDictionary
// I do not want to lock consumers form accessing other innerDictionaries
// while this computation is done.
this.PopulateInnerDictionary(innerDictionary);
}
finally
{
// I need to check this here incase an exception in the first
// try finally prevented this from being acquired
if (aquiredLockForInnerDictionary)
{
Monitor.Exit(innerDictionary);
}
}
}

Seems like you're overthinking it. The only question I have is, do you have a reliable way of knowing whether an inner dictionary instance has been populated? I would assume that a non-zero value for the Count property would suffice, no?
With that assumption, you can do this:
public Dictionary<TKey2, ReferenceTypedValues> SyncronizationExample1(Dictionary<TKey, Dictionary<TKey2, ReferenceTypedValues>> outerDictionary, TKey newKey)
{
Dictionary<TKey2, ReferenceTypedValues> innerDictionary = null;
lock (outerDictionary)
{
// No need to add a new innerDictionary if it already exists
if (!outerDictionary.TryGetValue(newKey, out innerDictionary))
{
innerDictionary = new Dictionary<TKey2, ReferenceTypedValues>();
outerDictionary.Add(newKey, innerDictionary);
}
}
// Found the inner dictionary, but might be racing with another thread
// that also just found it. Lock and check whether it needs populating
lock (innerDictionary)
{
if (innerDictionary.Count == 0)
{
this.PopulateInnerDictionary(innerDictionary);
}
}
return innerDictionary;
}
Notes:
It is not a good idea to use the object itself as the lock object, because you run the risk of some other code having the same bad idea and deadlocking with that code. Instead, store a composite value (e.g. Tuple<object, Dictionary<...>>, a custom named struct, etc.) that contains both the object to use for locking, and the inner dictionary itself. (And of course, have a single dedicated object stored in a field for locking the single outer dictionary.)
Your question doesn't describe how these objects are used. I'm guessing once populated, they are read-only? If so, the above should be fine, but you should use the ReadOnlyDictionary class to enforce that. Otherwise, you of course need to add synchronization for that too.
Even assuming they are read-only, your original code doesn't actually return the inner dictionary reference. I've modified the example slightly so that it does. It must. You can't have code looking for the reference without going through the checks in the code above. Best case scenario, it won't be fully populated yet, worst case scenario you'll crash due to trying to access the data structure while it's in an inconsistent state. You could by convention require that callers always call the above method before retrieving the reference value, but if they are going to do that, you might as well make it convenient and return the value from the method itself.

Dictionary is not safe if i only need to read values in threaded application?

I already have a initialized and filled Dictionary class i read values as below.
public class MyClass
{
public static Dictionary<string,object> Dictionary { get; set; }
public object Get(string key)
{
return Dictionary[key];
}
public List<object> Get(object type)
{
return Dictionary.Where(d=>d.Value == type);
}
}
As you can see that I have only 2 case that i just read values. If there is no any bad side effect in threaded app about above code so i will prefer to use Dictionary instead of using ConcurrentDictionary because of better performance.

Problems arise when threads are modifying the dictionary.
For example, at the same time, thread a is reading from the dictionary while thread b is changing some values. Thread a will get some changed values in his read.
In your case, you are always reading from the Dictionary so you will have no issues.

In theory this is fine, however this is not thread safe because you leave a public reference to the Dictionary via the property. It just depends on how paranoid you want to be in terms of protecting yourself from potential side effects down the road. Even if you pass a reference to the Dictionary into the constructor of my object and refer to is a private in the wrapping class, you still need to deep copy this parameter so that if the caller later modifies the Dictionary its keys/values are not mutated inside your wrapping class.
So as long as you're careful, your solution will work. You are leaving yourself open to potential thread safety issues however.

Multi-threaded management is for resoling race conditions and conflicts during the changing of the data (updating and writing) but for simple reading, if before you jump into the multi-threading you already done with with dictionary construction, you can avoid manage multi-threaded access.

Thread safe way of reading a value from a dictionary that may or may not exist

So, I've been spoiled by ConcurrentDictionary and it's awesome TryGetValue method. However, I'm constrained to using only regular Dictionary because this is in a portable class library targeting phone and other platforms. I'm trying to write a very limited subset of a Dictionary and exposing it in a thread-safe manner.
I basically need something like GetOrAdd from ConcurrentDictionary. Right now, I have this implemented like:
lock (lockdictionary)
{
if (!dictionary.ContainsKey(name))
{
value = new foo();
dictionary[name] = value;
}
value = dictionary[name];
}
Is this basically as good as I can get it? I think locking is only really required if the key doesn't exist and it gets added, however, there is no good "get value if it exists, return null otherwise" method. If I were to leave out the ContainsKey bit, when the key didn't exist I'd get an exception because the key doesn't exist.
Is there anyway I could get this to a more lean version? Or is this just the best a regular dictionary can do?

Locking is required even for reading in the presence of concurrent writers. So yes, this is as good as it gets if you mutate the dictionary.
You can of course always create a copy of the entire dictionary each time something is written. That way readers might see an out-of-date version but they can safely read.

You could try using ReaderWriterLockSlim. For example:
ReaderWriterLockSlim locker = new ReaderWriterLockSlim();
//..
public string GetOrAdd(string name)
{
locker.EnterUpgradeableReadLock();
try
{
if(!dictionary.ContainsKey(name))
{
locker.EnterWriteLock();
try
{
dictionary[name] = new foo();
}
finally
{
locker.ExitWriteLock();
}
}
value = dictionary[name];
}
finally
{
locker.ExitUpgradeableReadLock();
}
return value;
}

Your implementation is just fine. Note, that lock implementation has neglictable performance penalty in case of uncontended access. However, in order to achieve true thread-safety you must use lock with EVERY operation with dictionary - I suggest to write wrapper class, like SynchronizedDictinory to keep sync logic in one place

You can use a double-check pattern, as follows:
if (!dictionary.ContainsKey(name))
{
lock (lockdictionary)
{
if (!dictionary.ContainsKey(name))
{
value = new foo();
dictionary[name] = value;
}
value = dictionary[name];
}
}
This ensures you only lock if you actually need to, but also ensures once you have locked that you still need to add the value. The performance should be better than always locking. But don't take my word for it. Run a test!

This is as good as it gets.
Locking is required because dictionary makes no guarantees that you can update and read in parallel at all. Even single call to get element running at the same time as update on other thread may fail due to changes to internal data strucures.
Note that the behavior is explicitly covered in Thread Safety section of Dictionary
A Dictionary can support multiple readers concurrently, as long as the collection is not modified. Even so, enumerating through a collection is intrinsically not a thread-safe procedure. In the rare case where an enumeration contends with write accesses, the collection must be locked during the entire enumeration. To allow the collection to be accessed by multiple threads for reading and writing, you must implement your own synchronization.

Static methods updating a Dictionary<T,U> in ASP.NET - is it safe to lock() on the dictionary itself?

I have a class that maintains a static dictionary of cached lookup results from my domain controller - users' given names and e-mails.
My code looks something like:
private static Dictionary<string, string> emailCache = new Dictionary<string, string>();
protected string GetUserEmail(string accountName)
{
if (emailCache.ContainsKey(accountName))
{
return(emailCache[accountName]);
}
lock(/* something */)
{
if (emailCache.ContainsKey(accountName))
{
return(emailCache[accountName]);
}
var email = GetEmailFromActiveDirectory(accountName);
emailCache.Add(accountName, email);
return(email);
}
}
Is the lock required? I assume so since multiple requests could be performing lookups simultaneously and end up trying to insert the same key into the same static dictionary.
If the lock is required, do I need to create a dedicated static object instance to use as the lock token, or is it safe to use the actual dictionary instance as the lock token?

Collections in .NET are not thread safe so the lock is indeed required. An alternative to using the dictionary one could use Concurrent dictionaries introduced in .NET 4.0
http://msdn.microsoft.com/en-us/library/dd287191.aspx

Yes, the lock is required as long as code on other threads can/will access the static object.
Yes, its safe to lock on the dictionary itself, as long as its not accessible via a public getter. Then the caller might use the object for locking itself and that might result in deadlocks. So i would recommend to use a separate object to lock in if your dictionary is somewhat public.

The lock is indeed required.
By using lock, you ensure that only one thread can access the critical section at one time, so an additional static object is not needed.
You can lock on the dictionary object itself, but I would simply use a object lock =new object(); as my lock.

MSDN documentation specify that you should never use the lock() statement over a public object that can be read or modified outside your own code.
I would rather use an object instance rather than the object you attempt to modify, specifically if this dictionnary has accessors that allows external code to access it.
I might be wrong here, I didn't write a line of C# since one year ago.

Since the dictionary is private, you should be safe to lock on it. The danger with locking (that I'm aware of) is that other code that you're not considering now could also lock on the object and potentially lead to a deadlock. With a private dictionary, this isn't an issue.
Frankly, I think you could eliminate the lock by just changing your code to not call the dictionary Add method, instead using the property set statement. Then I don't believe the lock at all.
UPDATE: The following is a block of code from the private Insert method on Dictionary, which is called by both the Item setter and the Add method. Note that when called from the item setter, the "add" variable is set to false and when called from the Add method, the "add" variable is set to true:
if (add)
{
ThrowHelper.ThrowArgumentException(ExceptionResource.Argument_AddingDuplicate);
}
So it seems to me that if you're not concerned about overwriting values in your dictionary (which you wouldn't be in this case) then using the property setter without locking should be sufficient.

As far as I could see, additional object as a mutex was used:
private static object mutex = new object();
protected string GetUserEmail(string accountName)
{
lock (mutex)
{
// access the dictionary
}
}

Threading:Lock on generic dictionary

I have a generic dictionary in a multithreaded application; to implement a lock i created a property.
static object myLock=new object();
Dictionary<key,SomeRef> dict=new Dictionary<key,SomeRef>();
public Dictionary<key,SomeRef> MyDict{
get{
lock(myLock){
return dict;
}
}
}
Now if i write CODE#1
MyDict.TryGetValue
or CODE#2
var result=MyDict.Values;
foreach(var item in result){
//read value into some other variable
}
so while i m runnig code 1 or 2 and at the same time if some other thread tries to do some write operation on the dictionary like ..clear dict or add new item. then, will this solution be thread safe (using a property).
if not ..then is there any other ways to do this.
When i say write operation it can be take a reference of the dict through property chek key exoist or not if not create key and assign value. (thus me not using the setter in the property)

No, this will not be threadsafe.
The lock will only lock around getting the reference to your internal (dict) instance of the dictionary. It will not lock when the user tries to add to the dictionary, or read from the dictionary.
If you need to provide threadsafe access, I would recommend keeping the dictionary private, and make your own methods for getting/setting/adding values to/from the dictionary. This way, you can put the locks in place to protect at the granularity you need.
This will look something like this:
public bool TryGetValue(key thekey, out SomeRef result)
{
lock(myLock) { return this.dict.TryGetValue(thekey, out result); }
}
public void Add(key thekey, SomeRef value)
{
lock(myLock) { this.dict.Add(thekey, value) }
}
// etc for each method you need to implement...
The idea here is that your clients use your class directly, and your class handles the synchronization. If you expect them to iterate over the values (such as your foreach statement), you can decide whether to copy the values into a List and return that, or provide an enumerator directly (IEnumerator<SomeRef> GetValues()), etc.

No, this will not be safe, as the only code that's locked is the retrieval code. What you need to do is
lock(MyDict)
{
if(MyDict.TryGetValue()...
}
and
lock(MyDict)
{
foreach(var item in MyDict.Values) ...
}
The basic idea is to enclose your working code within the lock() block.

The implementation is not guaranteed to be thread safe as it is. In order to be thread safe concurrent reads/writes must all be protected by the lock. By handing out a reference to your internal dictionary, you're making it very hard to control who accesses the resource and thus you have no guarantee that the caller will use the same lock.
A good approach is to make sure whatever resources you're trying to synchronize access to is completely encapsulated in your type. That will make it much easier to understand and reason about the thread safety of the type.

Thread Safe Dictionary in .NET with ReaderWriterLockSlim
This is a method that uses ReaderWriterLockSlim and deterministic finalization to hold and release locks.