What is the use case of ConcurrentQueue<T>.TryPeek()?

Question

Inspired by my current problem, which is kind of identical to this: Analogue of Queue.Peek() for BlockingCollection when listening to consuming IEnumerable<T> with the difference that I - currently - am using ConcurrentQueue<T> instead of BlockingCollection<T>, I wonder what any use case for ConcurrentQueue<T>.TryPeek() may be?

Of course I mean a use case without manual lock(myQueue) stuff to serialize queue accesses as TPL is meant to improve/substitute those lockings.

Answer 1

I had an application that used ConcurrentQueue<T>.TryPeek to good effect. One thread was set up to monitor the queue. Mostly it was looking at queue size, but we also wanted to get an idea of latency. Because the items in the queue had a time stamp field that said what time they were put into the queue, my monitoring thread could call TryPeek to get the item at the head of the queue, subtract the insertion time from the current time, and tell me how long the item had been in the queue. Over time and many samples, that gave me a very clear picture of how long it was taking for a received item to be processed.

It didn't matter that some other thread might dequeue the item while my monitoring code was still examining it.

I can think of a few other scenarios in which it would be useful to see what's at the head of the queue, even though it might be pulled off immediately.

Answer 2

I have a ConcurrentQueue where many threads may Enqueue, but I limit just one thread doing TryPeek and TryDequeue by lock:

lock (dequeueLock)
    if (queue.TryPeek(out item))
        if (item.Value <= threshold)
            queue.TryDequeue(out item);

Note: other threads may continue to Enqueue while this code runs.

It would be nicer to have some atomic peek - check - dequeue operation, but the lock is fine for my scenario.