C# 只读不改队列是否应该使用lock语句？

Question

I am using list as a queue in my multithreading C# application. I am locking my custom Enqueue and Dequeue methods. Because multiple threads can call those methods.

From: https://learn.microsoft.com/en-us/do.net/csharp/language-reference/keywords/lock-statement I think I should but I would still ask the question here. Should I lock Peek method that is only telling me which element is at zero index? For the purpose of example consider that I have list(queue) of integers.

list = [1, 2, 2, 5]
Enqueue(list, 6)
// [1, 2, 2, 5, 6]

var element = Dequeue(list) // element = 1;
// [2, 2, 5, 6]

var peekElement = Peek(list) // peekElement = 2
// [2, 2, 5, 6]

Answer 1

Why not use ConcurrentQueue which will do your job easily?

var queue = new ConcurrentQueue<int>();

queue.Enqueue(1);
queue.Enqueue(2);

if (queue.TryPeek(out int firstValue))
    Console.WriteLine("Peek: " + firstValue);

if (queue.TryDequeue(out int result))
    Console.WriteLine("Dequeue: " + result);

https://learn.microsoft.com/en-us/do.net/api/system.collections.concurrent.concurrentqueue-1?view.netcore-3.1

Answer 2

You should lock.

I imagine that your Peek() method looks something like this:

public int Peek(List<int> list)
{
    if (list.Length < 1)
        throw new InvalidOperationException("Queue is empty");

    return list[0];
}

You are expecting it to throw an InvalidOperationException with message "Queue is empty" if you try to peek into an empty queue.

But now imagine this scenario with two threads, A and B:

1. Thread A calls Peek() for a list with one element.
2. Thread A executes if (list.Length < 1) and determines that the list is not empty, so it won't throw an exception.
3. Thread B calls Dequeue() and empties the list.
4. Thread A moves on to return list[0] and whoops - the list is empty so you get a completely different ArgumentOutOfRangeException exception.

Answer 3

Should I lock Peek method...?

Assuming you don't take Abhay's advice (see other answer) then yes.

The real purpose of locking a lock is to ensure that the thread which has just locked the lock will see shared variables in a state that is consistent with how they were left by some other thread that changed them before it released the same lock.

The list variable in your example has some internal representation that may be more complicated than just a simple array. If you allow some thread R to look at the list without locking a lock when some other thread W could modify the list at any time, you don't merely risk thread R seeing some out-of-date version of the list; you also risk thread R seeing a corrupt version of the list.

Even something as simple as asking for the length of the list could cause thread R to follow a bad pointer and crash the program, or worse.

Answer 4

No, you should not.

You should use a modified lock which is not a statement - a MUltipleReaderSingleWriter.

It allows multiple reads, but only ONE write and that only when there is no reader active.

Answer 5

From the documentation of the Queue<T> class:

Public static members of this type are thread safe. Any instance members are not guaranteed to be thread safe.

A Queue<T> 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> .

So if you call Peek from one thread while the queue is modified concurrently by other threads, without synchronizing properly the access to the queue using a lock or other means, you are breaking the guarantees offered by the manufacturer of the class. The behavior of the class becomes officially "undefined". This is not a good idea if you are trying to make a program that should be reliable regarding the correctness of its results.