Функции, которые может вызывать ISR
Следующий вопрос, за который следует взяться, — это список функций, которые может вызывать ISR.
Небольшое отступление. Исторически, причина основных затруднений при написании обработчиков прерываний заключалась (и в большинстве других операционных систем до сих пор заключается) в том, что ISR работают в особом окружении.
Одна из конкретных причин, усложняющих написание ISR, состоит в том, что с точки зрения ядра ISR на самом деле не является «полноправным» потоком. С позиции ядра это, если хотите, такой таинственный «аппаратный» поток. Это означает, что ISR не имеет права делать никаких манипуляций «на уровне потока» — таких как, например, обмен сообщениями, синхронизация, системные вызовы, дисковый ввод/вывод, и т.д.
Не усложняет ли это написание ISR? Конечно. И поэтому решение заключается в том, чтобы в самом теле обработчика выполнять минимум работы, а все остальное делать уже на уровне потока, где есть доступ ко всем сервисам.
Ваши цели при написании ISR должны заключаться в следующем:
• считать переменчивую (в оригинале было «transient» — прим. ред.) информацию;
• очистить источник прерывания;
• возможно, запланировать поток, который сделает реальную работу.
Такая «архитектура « держится на том, что QNX/Neutrino обеспечивает очень быстрые времена переключения контекста. Вы знаете, что сможете быстро переключиться в ваш обработчик для выполнения работы, критичной по времени. Вы также знаете, что когда обработчик возвратит событие для запуска потока, то поток тоже активизируется очень быстро. И именно эта философия «ничего не делайте в теле ISR» делает обработчики прерываний в QNX/Neutrino столь простыми!
Итак, какие же вызовы можно использовать в теле ISR? Вот официальный список:
• функции семейства atomic_*() (например, atomic_set());
• функции семейства mem*() (типа memcpy());
• большинство функций семейства str*() (типа strcmp()). Остерегайтесь, однако, потому что не все эти функции являются безопасными — например, strdup() вызывает malloc(), в которой используется мутекс, а это запрещено.
Вообще, что касательно строковых функций, перед их использованием надо индивидуально смотреть их описание в руководстве по Си-библиотеке;
• InterruptMask();
• InterruptUnmask();
• InterruptLock();
• InterruptUnlock();
• InterruptDisable();
• InterruptEnable();
• in*() и out*().
Основное эмпирическое правило формулируется примерно так: «Не используйте ничего, что требует большого объема стека или больших затрат времени, и не используйте ничего, что делает системные вызовы». Требование по стековому пространству проистекает из того факта, что ISR имеют очень ограниченный объем стека.
Список функций, безопасных для применения в ISR, имеет реальный смысл — например, если вам потребуется скопировать область памяти, хорошим выбором будет применение функций типа mem*() и str*(). Скорее всего, вам потребуется читать регистры аппаратных средств (например, чтобы сохранить какие-либо значения или очистить источник прерывания), тогда вам пригодятся функции ввода/вывода из семейств in*() и out*().
А как насчет ошарашивающего выбора функций семейства Interrupt*()? Давайте рассмотрим их попарно.
InterruptMask() и InterruptUnmask()
Эти функции ответственны за маскирование источника прерывания на уровне контроллера; это предохраняет прерывания от передачи процессору. Обычно эти функции применяются, когда вы хотите доделать работу в потоке, но не можете очистить источник прерывании непосредственно в теле ISR. В этом случае ISR должен вызвать InterruptMask(), а поток, после завершения работы, — InterruptUnmask().
Имейте в виду, что число вызовов InterruptUnmask() должно соответствовать числу вызовов InterruptMask() — чтобы прерывание продолжало работать, вы обязаны демаскировать его ровно столько раз, сколько раз оно было маскировано.
Заметьте, между прочим, что функция InterruptAttachEvent() выполняет InterruptMask() автоматически (в ядре), поэтому ваш обрабатывающий прерывание поток должен вызывать InterruptUnmask().
InterruptLock() и InterruptUnlock()
Эти функции используются для блокировки (InterruptLock()) и деблокировки (InterruptUnlock()) прерываний в одно- или многопроцессорной системе. Вам может понадобиться заблокировать прерывания, например, чтобы защитить поток от ISR (или, дополнительно, в SMP-системе — защитить ISR от потока). Когда вы сделаете нужные манипуляции с критическими данными, вы сможете деблокировать прерывания обратно. Отметьте, что данные функции рекомендованы к применению вместо известных вам функций InterruptDisable() и InterruptEnable(), потому что корректно работают в SMP-системах. По сравнению со «старыми» функциями, проверка на многопроцессорность вносит дополнительные издержки, но в однопроцессорной системе ими можно пренебречь, поэтому я рекомендую вам всегда использовать InterruptLock() и InterruptUnlock().
InterruptDisable() и InterruptEnable()
Не используйте эти функции в новых проектах. Исторически, эти функции применялись для вызова инструкций cli
и sti
в процессорах серии x86, когда QNX/Neutrino еще не была многоплатформенной ОС.
С тех пор функции были модернизированы для работы со всеми типами процессоров, но чтобы не огорчать SMP-системы, используйте лучше функции InterruptLock() и InterruptUnlock().
Еще одна вещь, которую не вредно будет повторить, заключается в том, что в SMP-системе возможно одновременное выполнение ISR и другого потока.
Резюме
При работе с прерываниями принимайте во внимание следующие положения:
• Не оставайтесь в обработчике прерывания слишком долго — выполняйте в нем минимальный объем работы. Это поможет сократить время реакции на прерывание и упростить отладку.
• Применяйте функцию InterruptAttach() только тогда, когда нужно обращаться к аппаратным средствам непосредственно после прерывания, в противном случае избегайте ее.
• Применяйте функцию InterruptAttachEvent() во всех других случаях. Ядро запланирует поток (на основе события, которое вы передадите) для обработки возникшего прерывания.
• Защищайте переменные, используемые как в обработчиках прерываний (при использовании InterruptAttach()), так и в потоках, путем вызова InterruptLock() и InterruptUnlock().
• Объявляйте переменные, используемые в качестве посредников между потоками и обработчиками прерывании, как volatile
, чтобы компилятор не кэшировал их «просроченные» значения, уже измененные обработчиком прерывания.