Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The Importance of Using Concurrent Collections in Multi-threaded Applications

DZone's Guide to

The Importance of Using Concurrent Collections in Multi-threaded Applications

Concurrent collections are particularly needed in multi-threaded apps. Here's an analysis architecture details that explain why.

· Java Zone
Free Resource

Microservices! They are everywhere, or at least, the term is. When should you use a microservice architecture? What factors should be considered when making that decision? Do the benefits outweigh the costs? Why is everyone so excited about them, anyway?  Brought to you in partnership with IBM.

This blog post is inspired by my observations from the field, including real customers and real applications.

Everybody knows the importance of using proper logic to synchronize data access across multiple threads, it is a very common question during technical interviews. The following example occurred with a number of customers and I would like to share it:

Key details about the architecture:

  1. Web applications are multi-threaded by default. Each request is served in a separate thread or even in multiple threads in case you are using asynchronous methods.
  2. When you share any data across the requests/threads it needs to be designed to provide concurrent access.
  3. Standard types are very well documented in MSDN whether they are thread-safe or not.
  4. Usually there are no issues in the synchronization until you put it under high load with a good variety of concurrent requests coming in.

The sample test I am going to use is a very basic ASP.NET application with WebAPI controller running in Azure. The application stores some internal data in the dictionary collection: System.Collections.Generic.Dictionary<string, string>.

These could be shared application settings, cached values for most commonly used data or anything else. Data is being accessed for both read and modify (add/remove). When I enable my application for monitoring and ran a heavy stress test I saw huge number of very slow calls, stalled requests and occasional failures.

The failures were due to ThreadAbortException and were caused by the IIS aborting the request due to processing timeout.

The error looks very standard unless you take a look into the performance call graph to understand where the time was spent.

 As you see above, the test application requests were stuck in Dictionary.FndEntry method, which isn’t something that you would expect–and no one expects that the application could spend two minutes getting a value from the Dictionary.

The way to fix it is very simple–use collections from System.Collections.Concurrent namespace, particularlyConcurrentDictionary<string, string> in my example. When I changed the code to leverage ConcurrentDictionary it fixed the performance and we didn’t capture any slow calls of failures due to timeouts.

The problem with using Dictionary in the web applications isn’t new but is still very actual, here is the great MSDN article for more information. 

Originally written by Alex Fedotyev

Discover how the Watson team is further developing SDKs in Java, Node.js, Python, iOS, and Android to access these services and make programming easy. Brought to you in partnership with IBM.

Topics:
.net

Published at DZone with permission of Christopher Lamb, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}