Using immutable collections for thread-safe read-only operations in .NET

Sometimes you have a scenario where multiple threads need to read from the same shared collection. We’ve looked at the 4 concurrent, i.e. thread-safe collection types on this blog that are available in the System.Collections.Concurrent namespace. They can be safely used for both concurrent writes and reads.

However, if your threads strictly only need to read from a collection then there’s another option. There are collections in the System.Collections.Immutable namespace that are immutable, i.e. read-only and have been optimisied for concurrent read operations.

Read more of this post

Using the BlockingCollection for thread-safe producer-consumer scenarios in .NET Part 5

In the previous post we finished the basics of building producer-consumer scenarios with BlockingCollection in .NET. In particular we saw how to send a signal to the consumer that the producers have completed their tasks and no more items will be inserted into the work queue.

In this final post I just want to draw your attention to a couple of other fine-tuning methods in the BlockingCollection object.

Read more of this post

Using the BlockingCollection for thread-safe producer-consumer scenarios in .NET Part 4

In the previous post we saw how to wire up the producer and the consumer in a very simplistic producer-consumer scenario in .NET using a BlockingCollection. We started a number of producer and consumer threads and checked their output in the Debug window.

In this post we’ll see how we can send a signal to the consumer that all producers finished adding new items to the work queue. This is to simulate a scenario where you can determine in advance when all expected items have been added to the work queue.

Read more of this post

Using the BlockingCollection for thread-safe producer-consumer scenarios in .NET Part 3

In the previous post of this mini-series we started building our model for the producer-consumer scenario. We have two objects to begin with. First, WorkTask.cs which represents the task that’s added to the work queue by the producers and retrieved by the consumers to act upon. Second we have an object, WorkQueue to encapsulate the work queue itself. It will be the consumer of the work queue through the MonitorWorkQueue method.

We haven’t yet seen the the consumer class yet. We’ll do that in this post.

Read more of this post

Using the BlockingCollection for thread-safe producer-consumer scenarios in .NET Part 2

In the previous post we briefly went through the producer-consumer scenario in general. We also mentioned another class in the System.Collections.Concurrent namespace that we haven’t seen before, i.e. the BlockingCollection of T.

We’ll start looking into this object in this post.

Read more of this post

Using the BlockingCollection for thread-safe producer-consumer scenarios in .NET Part 1

We’ve looked at the 4 concurrent, i.e. thread-safe collections available in .NET:

• ConcurrentDictionary
• ConcurrentQueue
• ConcurrentStack
• ConcurrentBag

We also mentioned that 3 of these, i.e. the concurrent queue, bag and stack implement the generic IProducerConsumer interface. They can be used in producer-consumer scenarios where one or more threads write to a work queue. They are the producers in the setup. One or more other threads then read from the same work queue in order to perform some task on them. These are the consumers. When the consumer takes an item from the work queue then that item is also removed from it so that it’s not processed more than once. If you need to build a scenario like that then you’ll obviously need thread-safe collections that can synchronise access to them in a reliable manner.

We haven’t seen before how a producer-consumer scenario can be built from scratch using the available classes in the System.Collections.Concurrent namespace. We’ll do that in this and the next couple of posts.

Read more of this post

A common platform for concurrent bags, stacks and queues in .NET

We’ve looked at the available concurrent collections in .NET before:

• ConcurrentStack
• ConcurrentBag
• ConcurrentQueue
• ConcurrentDictionary

3 of these objects implement the same interface. Can you guess which three are similar in some sense? Stacks, bags and queues differ from dictionaries in that elements in those collections cannot be retrieved by an index of any sort. You can take/pop/dequeue the elements one by one but you cannot get to element #3 without first removing all elements before that.

Read more of this post