I have a BlockingCollection. Producer tasks add items to it, and consumer tasks remove items.
Now I want to limit the number of items in the collection, automatically discarding old data if more items are added. The collection should never contain more than the N
most recently added items at the same time.
So, if the producers add new items faster than the consumers remove them, I want the consumers to process only the newest items.
I can limit the size of a BlockingCollection
in its constructor, but of course that just means it blocks when adding more items, not that it removes old items.
(I do not want blocking on the producer side, only the consumer side should block when retrieving items from an empty collection.)
My current solution is a hack, and only works for a size limit of 1:
(And I am not quite sure it works reliable at all.)
// My consumer task:
foreach (var item in blockingCollection.GetConsumingEnumerable())
{
var lastItem = item;
var lastItemTmp = item;
while (blockingCollection.TryTake(out lastItemTmp))
lastItem = lastItemTmp;
// Now lastItem contains the most recent item in the collection,
// and older items have been discarded.
// Proceed consuming lastItem ...
}
Is there a cleaner solution?
Do it this way:
void AddItemToQueue(MyClass item)
{
while (!queue.TryAdd(item))
{
MyClass trash;
queue.TryTake(out trash);
}
}
If the queue is full when you try to add the item, an item is removed from the queue. It uses TryTake
because it's possible (unlikely, but possible) that some other thread might have removed the last item from the queue before you get a chance to take one.
This assumes, of course, that you specified a limit on the number of items when you constructed the BlockingCollection
.
Another way to do this, although it's more involved, is to create your own circular queue class, and have it implement the IProducerConsumerCollection interface. You can then use an instance of that class as the backing collection for your BlockingCollection
. Implementing a circular queue isn't especially difficult, although there are edge cases that are tricky to get right. And you'll have to make it a concurrent data structure, although that's pretty easy to do with a lock.
If you don't expect the queue to overflow often, or if the queue is pretty low traffic (i.e. not being hit thousands of times per second), then my initial suggestion will do what you want and there won't be a performance problem. If there is a performance problem, then the circular queue is the solution.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With