Uses of a concurrent dictionary [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 11 years ago.

Where do you think one could find usages for the Concurrent Dictionary thats part of the .Net framework 4?

Has anybody used the Concurrent Dictionary, if so why? Examples if any would be great.

I can think of its uses in t开发者_高级运维he factory pattern wherein you want to store different instances of a class if it has been initialized already. Eg. Hibernates SessionFactory. What do you think?

---

I've used it heavily for caching scenarios. ConcurrentDictionary, especially when combined with Lazy<T>, is great for caching results when construction of a type is expensive, and works properly in multithreaded scenarios.

---

Whenever I don't want to worry about concurrent access to the dictionary really - i.e. I have some tiny HTTP web server app which logs/caches some request data in a dictionary structure - there can be any number of concurrent requests and I don't want to deal with having to manually lock the dictionary.

It's just one more thing that you don't have to do yourself and potentially get wrong, instead the framework takes care of that aspect for you.

---

We use it for caching objects in a multi-threaded app... performance is great and no worries about lock or similar...

---

Any basic cache that you need to be thread-safe is a candidate, especially for web apps that are inherently highly threaded. A dictionary requires a lock; either exclusive or reader/writer (the latter being more awkward to code). A hashtable is automatically thread-safe for readers (requiring a lock for writers), but often involves boxing of keys (and sometimes values), and has no static type safety.

A concurrent dictionary, however, is really friendly to use; no lock code, and entirely thread-safe. Less overhead than reader/writer locks (including the "slim" variety).