Многопоточная библиотека задач, Threading.Timer или темы?

Question

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

У каждой задачи есть интервал времени, когда она должна быть выполнена. У каждой задачи должен быть тайм-аут. Количество задач может быть бесконечным, нов обычных случаях около 100.

Итак, у нас есть список задач, которые должны выполняться через определенные промежутки времени, которые являются наилучшим решением?

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

Такое чувство, что мы злоупотребляем таймерами?Или это может сработать?

Другое решение - использовать таймеры для каждой задачи, но по истечении этого времени мы помещаем задачу в очередь, которая будет считываться некоторыми потоками, выполняющими эту работу?

Любые другие хорошие решения, которые я должен искать?

Answer 1

Информации не слишком много, но похоже, что вы также можете рассмотреть RX - проверьте больше на MSDN.com .

Вы можете думать о своих задачах как о сгенерированных событиях, которыедолжен быть составлен (запланирован) каким-то образом.Таким образом, вы можете сделать следующее:

• Создать отменяемые задачи с Observable.GenerateWithDisposable и вашими собственными Scheduler - проверьте больше на Пример Rx 101
• Задержка задачс Observable.Delay
• Ожидание задач с 'Observable.Timeout
• Составление задач любым предпочтительным способом

Еще раз вы можете проверить больше по указанным выше ссылкам.

Answer 2

Я делал что-то подобное раньше, когда было много объектов сокетов, которые нуждались в периодических запусках и таймаутах.Я использовал класс «TimedAction» с событиями «OnStart» и «OnTimeout» (классы сокетов и т. Д., Полученные из этого) и один поток, который обрабатывал все синхронизированные действия.Поток поддерживал список экземпляров TimedAction, упорядоченный по времени тика следующего требуемого действия (дельта-очередь).Объекты TimedAction были добавлены в список путем помещения их в очередь ввода потока.Поток ожидал в этой входной очереди с тайм-аутом (это была Windows, поэтому «WaitForSingleObject» на дескрипторе семафора, который управлял очередью), установленным на счетчик тиков «требуется следующее действие» первого элемента в списке.Если время ожидания очереди истекло, было вызвано соответствующее событие действия первого элемента в списке, и элемент был удален из списка - следующее ожидание очереди будет установлено новым «первым элементом в списке», который будет содержатьновое «время ближайшего действия».Если в очередь поступило новое действие TimedAction, поток рассчитал время его таймаута (GetTickCount + мс интервал от объекта) и вставил его в отсортированный список в правильном месте (да, это иногда означало перемещение большого количества объектоввверх по списку, чтобы освободить место).

События, вызываемые потоком обработчика тайм-аута, не могут предпринимать длительных действий, чтобы предотвратить задержки при обработке других тайм-аутов.Как правило, обработчики событий устанавливают некоторое перечисление состояния, сигнализируют какой-либо объект синхронизации или ставят в очередь TimedAction в какой-либо другой порт ПК или порт завершения ввода-вывода.

Имеет ли это смысл?Он работал нормально, обрабатывая тысячи синхронизированных действий на моем сервере достаточно своевременно и эффективно.

Одним из улучшений, которое я планировал сделать, было использование нескольких списков с ограниченным набором интервалов времени ожидания.В моей системе было только три интервала тайм-аута, поэтому я мог использовать три списка, по одному для каждого интервала.Это будет означать, что списки не будут нуждаться в явной сортировке - новые TimedActions всегда будут идти в конец их списка.Это исключило бы дорогостоящую вставку объектов в середину списка / ов.Я так и не удосужился сделать это, так как мой первый дизайн работал достаточно хорошо, и у меня было множество других ошибок, которые нужно исправить: (

Две вещи:

Остерегайтесь 32-битного ролика тика.

Вам необходим цикл в блоке тайм-аута очереди - в списке могут быть элементы с одинаковым или почти одинаковым числом тиков тайм-аута. Как только тайм-аут очереди наступит, вам нужно удалить его из списка и запустить событиякаждого объекта до тех пор, пока вновь рассчитанное время ожидания не станет> 0. Я не справился с этим. Два объекта с одинаковым числом тактов тайм-аута прибыли в начало списка. Один получил свои события, но счетчик системных тиков перешел ипоэтому расчетное время ожидания для следующего объекта было равно -1: БЕСКОНЕЧНО! Мой сервер перестал работать правильно и в итоге заблокирован: (

Rgds, Martin

Answer 3

Вы должны проверить Quartz.NET .

Quartz.NET - это полнофункциональный, открытый система планирования работы источника, которая может использовать от самых маленьких приложений до больших Системы масштаба предприятия.

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