VisualStudioFeeds

All Visual Studio blogs in one place

AddThis Social Bookmark Button
Using locks to implement a thread-safe collection is rather like using a sledgehammer - unsubtle, easy to understand, and tends to make any other tool redundant. Unlike the previous two collections I looked at, ConcurrentStack and ConcurrentQueue, ConcurrentDictionary uses locks quite heavily. However, it is careful to wield locks only where necessary to ensure that concurrency is maximised. This will, by necessity, be a higher-level look than my other posts in this series, as there is quite a lot of code and logic in ConcurrentDictionary. Therefore, I do recommend that you have ConcurrentDictionary open in a decompiler to have a look
at all the details that I skip over. The problem with locks There's several things to bear in mind when using locks, as encapsulated by the lock keyword in C# and the System.Threading.Monitor class in .NET (if you're unsure as to what lock does in C#, I briefly covered it in my first post in the series): Locks block threads
The most obvious problem is that threads waiting on a lock can't do any work at all. No preparatory work, no 'optimistic' work like in ConcurrentQueue and ConcurrentStack, nothing. It sits there, waiting to be unblocked. This is bad if you're trying to...(Read whole news on source site)

Search

Subscribe

Enter your email address:

Delivered by FeedBurner

Increase your website traffic with Attracta.com

Contact

Email:
Subject:
Message:
Anti-spam: How many eyes has a typical person?

Follow us on FB

Home : Blog List : Simon Cooper : Inside the Concurrent Collections: ConcurrentDictionary