Книга: Введение в QNX/Neutrino 2. Руководство по программированию приложений реального времени в QNX Realtime Platform

Периодические процессы

Периодические процессы

Так как же обеспечивается «периодическая» работа системы диагностики? Можно вообразить себе некоторый процесс, выполняемый процессором нашего автомобиля и делающий нечто подобное следующему:

// Процесс диагностики
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 секунд.

• В обработчике прерываний сравнивает эту переменную с текущим временем.

• Когда текущее время станет равным (или больше) данной переменной, поток снова ставится в очередь готовности.

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

Оглавление книги