Queue.Peek поток безопасен?

Question

Операция чтения 32-битного поля является атомарной. Поэтому, если в очереди хранятся ссылки на объекты, метод Queue.Peek должен быть потокобезопасным, верно?

Answer 1

Нет. И даже если бы это было так, это не относится к делу. Давайте на мгновение предположим потокобезопасный взгляд. Обычно вы пишете код, который делает что-то вроде этого:

if (MyQueue.Peek() != null)
  var item = MyQueue.Dequeue();

Это ошибка в многопоточном коде, даже если Peek() и Dequeue() оба являются поточно-ориентированными, потому что вы должны помнить, что очередь может меняться между проверками с помощью Peek () и когда вы действуете на информацию, которую он дает вам с Dequeue (). Вы должны убедиться, что вы фиксируете вокруг обе детали.

Answer 2

Нет, вы все равно должны блокироваться вокруг каждого Peek() вызова.

Поскольку Queue внутренне использует массив, его методы экземпляра не являются поточно-ориентированными, поскольку массив может быть изменен другим потоком в любое время.

Peek() также проверяет длину очереди, чтобы увидеть, есть ли элементы в очереди, прежде чем возвращать фактическое значение, и какой-то другой поток может удалить эти элементы, прежде чем метод фактически вернет эти значения.

Answer 3

Если вы посмотрите на реализацию в .net рефлектор, она выглядит следующим образом ...

public virtual object Peek()
{
    if (this._size == 0)
    {
        throw new InvalidOperationException(Environment.GetResourceString("InvalidOperation_EmptyQueue"));
    }
    return this._array[this._head];
}

Так нет. Не потокобезопасен.

Answer 4

Это не потокобезопасно.

Но для синхронизации вы можете найти ReaderWriterLockSlim лучшим. Только методы Enqueue() и Dequeue() требуют блокировки записи. Peek() потребует только блокировки чтения.