Синхронизация потоков с монитором и WaitHandle

Ответ 1

Проблема с Monitor.Pulse/Wait заключается в том, что сигнал может потеряться.

Например:

var signal = new ManualResetEvent(false);

// Thread 1
signal.WaitOne();

// Thread 2
signal.Set();

Это всегда будет работать независимо от того, выполняются ли два оператора в разных потоках. Это также очень чистая абстракция и очень четко выражает ваши намерения.

Теперь рассмотрим тот же пример с помощью монитора:

var signal = new object();

// Thread 1
lock (signal)
{
    Monitor.Wait(signal);
}

// Thread 2
lock (signal)
{
    Monitor.Pulse(signal);
}

Здесь сигнал (Pulse) потеряется, если Pulse выполняется до Wait.

Чтобы устранить эту проблему, вам нужно что-то вроде этого:

var signal = new object();
var signalSet = false;

// Thread 1
lock (signal)
{
    while (!signalSet)
    {
        Monitor.Wait(signal);
    }
}

// Thread 2
lock (signal)
{
    signalSet = true;
    Monitor.Pulse(signal);
}

Это работает и, вероятно, еще более совершенным и легким, но менее читаемым. И там, где начинается головная боль, называемая concurrency.

• Действительно ли этот код работает?
• В каждом угловом случае?
• С более чем двумя потоками? (Подсказка: это не так)
• Как вы его тестируете?

Твердая, надежная, читаемая абстракция часто лучше, чем сырая производительность.

Кроме того, WaitHandles предоставляют некоторые приятные вещи, такие как ожидание набора ручек, которые будут установлены, и т.д. Внедрение этого с помощью мониторов делает головную боль еще хуже...

Общее правило:

• Используйте Мониторы (lock), чтобы обеспечить эксклюзивный доступ к общему ресурсу
• Используйте WaitHandles (Manual/AutoResetEvent/Semaphore) для отправки сигналов между потоками

Ответ 2

Я думаю, что у меня неплохой пример 3-го пуля (и хотя этот поток немного стар, он может помочь кому-то).

У меня есть код, в котором поток A получает сетевые сообщения, помещает их в очередь, а затем передает поток B. Потоки B блокируют, деактивируют любые сообщения, разблокируют очередь, затем обрабатывают сообщения.

Проблема заключается в том, что в то время как Thread B обрабатывает и не ждет, если A получает новое сетевое сообщение, завершает и подает импульсы... ну, B не ждет, чтобы импульс просто испарялся. Если B заканчивает то, что он делает, и нажимает на Monitor.Wait(), то недавно добавленное сообщение будет просто зависать, пока не поступит другое сообщение и не будет получен импульс.

Обратите внимание, что эта проблема на самом деле не выглядела некоторое время, так как изначально весь мой цикл был примерно таким:

while (keepgoing)
  { 
  lock (messageQueue)
      {
      while (messageQueue.Count > 0)
          ProcessMessages(messageQueue.DeQueue());

      Monitor.Wait(messageQueue);
      }
  }

Эта проблема не возникала (ну, при отключении были редкие странности, поэтому я немного подозрительно относился к этому коду), пока не решил, что обработка сообщений (потенциально длительная работа) не должна блокировать очередь в виде у него не было причин. Поэтому я изменил его, чтобы удалить сообщения из сообщения, оставьте блокировку, ТОГДА выполните обработку. И тогда мне показалось, что я начал пропускать сообщения, или они придут только после того, как произошло второе событие...

Ответ 3

для случая @Will Gore, рекомендуется всегда продолжать обработку очереди до тех пор, пока она не будет пустой, перед вызовом Monitor.Wait. Например:.

while (keepgoing)
{ 
  List<Message> nextMsgs = new List<Message>();
  lock (messageQueue)
  {
    while (messageQueue.Count == 0)
    {
        try
        {
            Monitor.Wait(messageQueue);
        }
        catch(ThreadInterruptedException)
        {
            //...
        }
    }
    while (messageQueue.Count > 0)
        nextMsgs.Add(messageQueue.DeQueue());
  }
  if(nextMsgs.Count > 0)
    ProcessMessages(nextMsgs);
}

это должно решить проблему, с которой вы столкнулись, и сократить время блокировки (очень важно!).