Альтернатива опросу для планировщика заданий

Question

Нам нужен рабочий сервер здесь, на работе, и я в настоящее время играю с Quartz.net, но идея создания моей собственной привлекательности для меня.По крайней мере, понимание того, что Quartz.net может делать под прикрытием, не может повредить моему пониманию / шансам использовать его более эффективно.

Итак, мой вопрос, как бы вы пошли на то, чтобы получить и уволить работу с темы без опроса?Если вы проверяете свой «магазин работ» каждые 2 минуты на наличие работ, которые нужно уволить, у вас будет задержка примерно на 2 минуты.Если вы уменьшите время опроса, вы увеличите нагрузку на свой склад вакансий, и все равно не получите истинного времени запуска.Вы можете предварительно загрузить задания для следующего двухминутного сегмента и перевести потоки в спящий режим на оставшееся время, чтобы они запускались в нужное время, но это выглядит глупо и может привести к проблемам, если время опроса велико (удаление, перепланирование и т. Д.). I 'Я анализирую Кварц, чтобы выяснить, как он это делает, но мне было интересно, упустил ли я что-то фундаментальное.

РЕДАКТИРОВАТЬ:

Многопоточная структура, подобная описанной вначале Кевином, кажется, вам СЛЕДУЕТ сделатьработа сервера.Это дает вам максимальную гибкость при минимальных затратах.Поскольку потоки - это лакомый кусочек для работы с большинством людей (может быть, только со мной :), более простой пример опроса выполнит работу в 90% случаев за счет потери гибкости и больших накладных расходов.

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

Я также согласен с Кевином в том, что вещи, которые вы утверждаете, вы получаете бесплатно в примере с опросом БД, на самом деле не бесплатны.Вы собираетесь кодировать вещи так же, как если бы это было потоковое / ожидающее приложение.Что делать, если ваш сервер заданий на опрос дБ взорвется в середине работы?Оба будут полагаться на какое-то долговременное хранилище для отслеживания своего состояния в случае аварии.

Что если вы переместите 'хранилище заданий' на уровень абстракции, и он не будет основан на обычном ACID (верно?срок?) база данных.Теперь то, на чем я полагаю, что многие из ваших «бесплатных» материалов больше не доступны (транзакции?).

Answer 1

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

Единственная хитрость - поток должен ждать, основываясь на некоторой условной переменной.Условная переменная может быть передана в случае изменения заголовка очереди.Обычно с помощью условных переменных вы можете определить, был ли он сигнализирован, а время ожидания истекло.Таким образом, если это было сигнализировано, вы просто повторно ждете нового времени заголовка, в противном случае тайм-аут указывает, что пришло время запустить задачу в начале очереди.

Это решение означает, что у вас есть только один поток для управления задачами, и он не опрашивает.

РЕДАКТИРОВАТЬ:

Я обновлю свое решение, чтобы указать, что оно, вероятно,не очень хорошая идея написать свой собственный планировщик, учитывая, что кварц - очень хорошее решение.Кроме того, я думаю, что опрос каждую секунду является излишним, поскольку задания обычно выполняются поминутно, а не посекундно.Например, вас действительно волнует, если работа начинается в 12:00:05 или достаточно 12:00:00?В любом случае, вы можете параметризовать свой опрос так, чтобы он соответствовал необходимому уровню детализации.