CODEWITHSUNDEEP
c#multithreadingqueuethread-safetyconcurrent-queue
user1080381
user1080381

Reputation: 1786

Difference between Queue's and Concurrent Queue's TryDequeue method

Both collections, Queue and ConcurrentQueue have a method TryDequeue. What is the difference between using TryDequeue with Queue and ConcurrentQueue respectively? Is Queue's TryDequeue method thread-safe in multi-threading environment?

Upvotes: 2

Views: 1041

Answers (3)

user585968
user585968

Reputation:

TL; DR: "Any instance members are not guaranteed to be thread safe. A Queue can support multiple readers concurrently, as long as the collection is not modified. Even so, enumerating through a collection is intrinsically not a thread-safe procedure. For a thread-safe queue, see ConcurrentQueue<T>.", learn.microsoft.com

Background

OP:

Both collections, Queue and ConcurrentQueue have a method TryDequeue. What is the difference between using TryDequeue with Queue and ConcurrentQueue respectively?

If we take a look at the "Remarks" section of Queue we see:

MSDN (my emphasis):

Public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.1

Interestingly, though with dragons, there is this additional point (again my emphasis):

A Queue can support multiple readers concurrently, as long as the collection is not modified. Even so, enumerating through a collection is intrinsically not a thread-safe procedure. For a thread-safe queue, see ConcurrentQueue.1

OP:

Is Queue's TryDequeue method thread-safe in multi-threading environment?

So it would appear Queue<T> has some concurrent features though great care must be undertaken on the part of the user whilst doing so (ensuring the queue is not modified).

Now let's compare that with something written from the ground up with concurrency in mind - ConcurrentQueue<T>.

First a word from MSDN:

Represents a thread-safe first in-first out (FIFO) collection.

All public and protected members of ConcurrentQueue are thread-safe and may be used concurrently from multiple threads.2

So this is confirmation that any instance method of ConcurrentQueue<T> is thread-safe, unlike Queue<T>.

TryDequeue compared

The documentation for the definition of both methods begins essentially the same:

Removes the object at the beginning of the Queue, and copies it to the result parameter.3

Tries to remove and return the object at the beginning of the concurrent queue.4

...however we already know that Queue<T> instance methods are not thread safe for concurrent read/write. ConcurrentQueue<T> being the champ that is ends the match with a detailed explanation as to the internal workings:

ConcurrentQueue handles all synchronization internally. If two threads call TryDequeue at precisely the same moment, neither operation is blocked. When a conflict is detected between two threads, one thread has to try again to retrieve the next element, and the synchronization is handled internally.4

...and:

TryDequeue tries to remove an element from the queue. If the method is successful, the item is removed and the method returns true; otherwise, it returns false. That happens atomically with respect to other operations on the queue.4

Tell me more

1 "Thread safety - Queue class", Microsoft

2 ConcurrentQueue Class, Microsoft

3 Queue<T>.TryDequeue(T) Method, Microsoft

4 ConcurrentQueue.TryDequeue(T) Method, Microsoft

Upvotes: 1

Matthew Watson
Matthew Watson

Reputation: 109587

Queue.TryDequeue() is not threadsafe.

We can look at its implementation for proof:

public bool TryDequeue([MaybeNullWhen(false)] out T result)
{
    int head = _head;
    T[] array = _array;

    if (_size == 0)
    {
        result = default;
        return false;
    }

    result = array[head];
    if (RuntimeHelpers.IsReferenceOrContainsReferences<T>())
    {
        array[head] = default!;
    }
    MoveNext(ref _head);
    _size--;
    _version++;
    return true;
}

It's easy to see that isn't threadsafe. Just the _size-- alone is not threadsafe.

But even without the source code, the documentation for Queue<T> explicitly states:

Any instance members are not guaranteed to be threadsafe.

Of course, the methods of ConcurrentQueue are threadsafe, and by definition ImmutableQueue is also threadsafe.

(The Try in the name of TryDequeue() is referring to the fact that it handles an empty queue rather than anything to do with thread safety.)

Upvotes: 3

Marc Gravell
Marc Gravell

Reputation: 1062915

Nothing on Queue<T> is thread-safe - not even Count

The difference is entirely: thread-safety. On ConcurrentQueue<T>, yes: it is thread-safe. There are also some minor API differences (the lack of Dequeue() on the concurrent version, for example), but mostly: the API shape is directly comparable, give or take thread-safety.

Upvotes: 2

Related Questions