Периодические процессы
Периодические процессы
Так как же обеспечивается «периодическая» работа системы диагностики? Можно вообразить себе некоторый процесс, выполняемый процессором нашего автомобиля и делающий нечто подобное следующему:
// Процесс диагностики
int main(void) // Игнорируем аргументы
{
for (;;) {
perform_diagnostics();
sleep(15);
}
// Сюда мы не дойдем
return (EXIT_SUCCESS);
}
Видно, что процесс диагностики выполняется бесконечно. Он запускает цикл работ по диагностике, затем «засыпает» на 15 секунд, потом «просыпается», и все повторяется заново.
Если оглянуться назад в мрачные и смутные однозадачные времена, когда один процессор обслуживал одного пользователя программы такого сорта реализовывались путем выполнения функцией sleep() активного ожидания. Для этого вам было необходимо узнать быстродействие вашего процессора и написать свою собственную функцию sleep(), например:
void sleep(int nseconds) {
long i;
while (nseconds--) {
for (i = 0; i < CALIBRATED_VALUE; i++);
}
}
В те дни, поскольку в машине не выполнялось никаких других задач, такие программы не составляли большой проблемы, поскольку никакой другой процесс не беспокоило, что вы используете своей функцией sleep() все 100% ресурсов процессора.
Даже в наши дни мы иногда отдаем все 100% ресурсов процессора, чтобы отмерить время. В частности, функция nanospin() применяется для отсчета времени с очень большой точностью, но делает это за счет монопольного захвата процессора на своем приоритете. Пользуйтесь с осторожностью!
Если вы должны были реализовать некоторое подобие «многозадачного режима», то это обычно делалось путем применения процедуры прерывания, которая либо срабатывала от аппаратного таймера, либо выполнялась в пределах периода «активного ожидания», оказывая при этом некоторое воздействие на калибровку отсчета времени. Это обычно не вызывало беспокойства.
К счастью, в решении этих проблем мы уже ушли далеко вперед. Вспомните параграф «Диспетчеризация и реальный мир» (глава «Процессы и потоки»), там описываются причины, по которым ядро выполняет перепланирование потоков. Причины могут быть следующие:
• аппаратное прерывание;
• системный вызов;
• сбой (исключение).
В данной главе мы подробно проанализируем две первые причины из вышеуказанного списка — аппаратные прерывания и системные вызовы.
Когда поток вызывает функцию sleep(), код, содержащийся в Си-библиотеке, в конечном счете делает системный вызов. Этот вызов приказывает ядру отложить выполнение данного потока на заданный интервал времени. Ядро удаляет поток из рабочей очереди и включает таймер.
Все это время ядро принимает регулярно поступающие аппаратные прерывания таймера. Положим для определенности, что эти аппаратные прерывания происходят ровно каждые 10 миллисекунд.
Давайте немного переформулируем это утверждение: каждый раз, когда такое прерывание обслуживается соответствующей подпрограммой обработки прерывания (ISR) ядра, это значит, что истек очередной 10-миллисекундный интервал. Ядро отслеживает время суток путем увеличения специальной внутренней переменной на значение, соответствующее 10 миллисекундам, с каждым вызовом обработчика прерывания.
Так что, реализуя 15-секундный таймер, ядро в действительности выполняет следующее:
• Устанавливает переменную в текущее время плюс 15 секунд.
• В обработчике прерываний сравнивает эту переменную с текущим временем.
• Когда текущее время станет равным (или больше) данной переменной, поток снова ставится в очередь готовности.
При использовании множества параллельно работающих таймеров — например, когда необходимо активизировать несколько потоков в различные моменты времени — ядро просто ставит запросы в очередь, отсортировав таймеры по возрастанию их времени истечения (в голове очереди при этом окажется таймер с минимальным временем истечения). Обработчик прерывания будет анализировать только переменную, расположенную в голове очереди.