Question

I have a bounded blocking queue in an application that was written several years ago. Let’s just say that the implementation is less than stellar, but it’s worked. However, it has some performance problems. It looks like the .NET 4.0 BlockingCollection<T> is the right replacement, but I need to make sure that it is actually a queue. That is, is it guaranteed to be strictly FIFO if used in a single-producer, single-consumer fashion?

The documentation doesn’t specifically say. The BlockingCollection topic does say (in the Remarks):

BlockingCollection<T> is similar to a
traditional blocking queue data
structure, except that the underlying
data storage mechanism is abstracted
away as an IProducerConsumerCollection<T>.

But nothing specifically says that things will be removed in the same order they’re added.

Anybody know for sure?

Answer 1

Well, BlockingCollection<T> is really designed for parallel work, where you have multiple simulataneous “producers” and one consumer (using GetConsumingEnumerable()).

In this situation, you have no way to guarantee insertion order, so the ordering constraints aren’t specified.

That being said, BlockingCollection<T> works upon any IProducerConsumerCollection<T> (specified in the constructor). If you don’t provide one in the constructor, internally, it will use a ConcurrentQueue<T>. This causes it to be FIFO, since it will actually be (internally) a queue. So yes, by default, it will be “guaranteed to be strictly FIFO if used in a single-producer, single-consumer fashion”, at least in the current implementation. If you want to force this for future proofing (since the queue is an implementation detail), just construct it as:

var blockingCollection = new BlockingCollection<MyClass>(new ConcurrentQueue<MyClass>());

That will guarantee that it uses a queue now, and in the future (since the queue is an implementation detail).