Разница между событиями и прерываниями
Я знаю, что эта тема обсуждалась давно (ссылка: Разница между прерыванием и событием ), хотя я не считаю ответ адекватным. Причина в следующем: когда говорят о событиях в сравнении с прерываниями, термин «события» означает что-то об оборудовании, а не о программном обеспечении. Более того, согласно этому объяснению, событие предсказуемо, а не то, что происходит внезапно, но в случае события пробуждения это не может быть правдой, потому что это событие не «ожидаемое», это что-то спонтанное.
1 ответ
События - это концепция более высокого уровня абстракции, обычно встречающаяся в системном или прикладном программировании. Они не обязательно основаны на оборудовании, но могут запускаться исключительно программным обеспечением. Единого определения этого термина нет, оно довольно широкое.
С другой стороны, прерывания всегда запускаются оборудованием на самом низком уровне. Еще один термин - аппаратные исключения, ядра верхнего уровня и микроконтроллеры часто разделяют их как что-то, выбрасываемое ядром или контролирующим оборудованием, когда возникает какое-то ненормальное состояние (недопустимая инструкция, деление на ноль, ошибки доступа к памяти и т. Д.). В то время как источники прерывания могут быть либо ожидаемым поведением оборудования, либо некоторой ошибкой.
Прерывания и аппаратные исключения требуют, чтобы функция-обработчик была зарегистрирована в аппаратной справочной таблице, часто называемой таблицей векторов прерываний. Оборудование будет обращаться к этой таблице при возникновении прерывания, чтобы найти адрес вызываемой функции - такие функции называются процедурами обслуживания прерываний (ISR). Будет специальное соглашение о вызовах прерываний, в котором определенные регистры складываются аппаратным обеспечением перед вызовом ISR, а специальные инструкции возврата из используются для восстановления регистров после завершения ISR.
Однако в событиях используются программные функции обратного вызова, как правило, когда приложение передает указатель на функцию при создании события. Обычно они используются в прикладном программировании и инструментах быстрой разработки приложений (RAD). Во встроенных системах можно создать нечто подобное, позволив приложению зарегистрировать ряд обратных вызовов для определенных вещей, которые происходят внутри драйвера, а затем позволить драйверу вызвать обратный вызов. Но даже несмотря на то, что драйвер представляет собой код самого низкого уровня поверх оборудования, он по-прежнему является программным и выполняет вызов, созданный программным обеспечением.
Но поскольку «событие» - это такой широкий термин, в некоторых случаях события - это объекты, которые можно использовать вместе с более широкими функциями API. И тогда у них не обязательно есть функция обратного вызова - они, по сути, просто флаги. В ОС Windows, например, прикладной программист может создать событие, чтобы сигнализировать что-то запущенному потоку, после чего поток может использовать эффективную функцию ожидания ЦП и ждать, пока не будет получено событие. Это один из обычных способов правильно остановить поток, позволяя ему корректно завершиться самостоятельно.
Что общего у прерываний и событий, так это то, что они оба приводят к эффективному, но недетерминированному выполнению. Программа может делать другие вещи, когда прерывание / событие не сработало, и ей не нужно использовать опрос какого-либо флага, который является альтернативой прерываниям. Но когда он срабатывает, он прерывает текущее выполнение и прерывает его, выполняя что-то еще. Кроме того, он помещает дополнительный вызов в стек в дополнение к текущему стеку вызовов, поэтому, если это произойдет, когда программа находится на самом глубоком уровне вызова, вы можете получить очень тонкие ошибки, такие как периодическое переполнение стека.
Еще одна проблема с прерываниями и, возможно, с событиями, заключается в том, что они чаще всего действуют как отдельные потоки со всеми вытекающими из них проблемами безопасности потоков. Вам нужно будет защитить переменные, совместно используемые с ISR/ обратным вызовом, от ошибок состояния гонки, либо семафорами, либо гарантируя атомарный доступ. Я бы сказал, что невыполнение этого требования является самой распространенной ошибкой во встраиваемых системах за все время. Это тоже создает невероятно тонкие ошибки.