Резервная очередь очереди - Enqueue/Dequeue
Во-первых, я объясню короткий сценарий;
В качестве сигнала от некоторых триггеров устройств в очередь добавляется объект типа Alarm. С интервалом проверяется очередь, и для каждого Тревоги в очереди он запускает метод.
Однако проблема, с которой я сталкиваюсь, заключается в том, что, если в очередь добавляется будильник, пока он проходит, он выдает ошибку, чтобы сказать, что очередь изменилась, пока вы ее использовали. Здесь немного кода, чтобы показать свою очередь, просто предположите, что в него постоянно вставляются сигналы тревоги;
public class AlarmQueueManager
{
public ConcurrentQueue<Alarm> alarmQueue = new ConcurrentQueue<Alarm>();
System.Timers.Timer timer;
public AlarmQueueManager()
{
timer = new System.Timers.Timer(1000);
timer.Elapsed += new System.Timers.ElapsedEventHandler(timer_Elapsed);
timer.Enabled = true;
}
void timer_Elapsed(object sender, System.Timers.ElapsedEventArgs e)
{
DeQueueAlarm();
}
private void DeQueueAlarm()
{
try
{
foreach (Alarm alarm in alarmQueue)
{
SendAlarm(alarm);
alarmQueue.TryDequeue();
//having some trouble here with TryDequeue..
}
}
catch
{
}
}
Итак, мой вопрос: как мне сделать это более... потокобезопасным? Чтобы я не столкнулся с этими проблемами. Возможно, что-то вроде того, копируя очередь в другую очередь, работая над этим, а затем удаляя тревоги, которые были обработаны из исходной очереди?
edit: только что было сообщено о параллельной очереди, проверит это сейчас
Ответы
Ответ 1
private void DeQueueAlarm()
{
Alarm alarm;
while (alarmQueue.TryDequeue(out alarm))
SendAlarm(alarm);
}
В качестве альтернативы вы можете использовать:
private void DeQueueAlarm()
{
foreach (Alarm alarm in alarmQueue)
SendAlarm(alarm);
}
В статье MSDN на ConcurrentQueue<T>.GetEnumerator
:
Перечисление представляет собой моментальный снимок содержимого очереди. Он не отражает никаких обновлений коллекции после того, как был вызван GetEnumerator
. Перечислитель безопасен для использования одновременно с чтением и записью в очередь.
Таким образом, разница между двумя подходами возникает, когда ваш метод DeQueueAlarm
вызывается одновременно несколькими потоками. Используя подход TryQueue
, вам гарантируется, что каждый Alarm
в очереди будет обрабатываться только один раз; однако, какой поток выбирает, какой сигнал тревоги определяется недетерминированно. Подход foreach
гарантирует, что каждый гоночный поток будет обрабатывать все тревоги в очереди (по состоянию на момент, когда он начал перебирать их), в результате чего один и тот же сигнал обрабатывается несколько раз.
Если вы хотите обработать каждый аварийный сигнал ровно один раз и впоследствии удалить его из очереди, вы должны использовать первый подход.
Ответ 2
Любые причины, по которым вы не можете использовать ConcurrentQueue<T>
Ответ 3
.Net уже имеет поточную реализацию очереди: посмотрите ConcurrentQueue.
Ответ 4
Лучший способ приблизиться к нему, учитывая, что каждый поток фактически обрабатывает только один сигнал тревоги сразу, заменит это:
foreach (Alarm alarm in alarmQueue)
{
SendAlarm(alarm);
alarmQueue.TryDequeue();
//having some trouble here with TryDequeue..
}
с этим:
while (!alarmQueue.IsEmpty)
{
Alarm alarm;
if (!alarmQueue.TryDequeue(out alarm)) continue;
SendAlarm(alarm);
}
Нет никаких оснований для получения полного моментального снимка очереди в любое время, потому что вы действительно заботитесь о следующем, чтобы обрабатывать в начале каждого цикла.