Метод опроса или прерывания

Question

Когда следует использовать метод опроса и когда следует использовать метод на основе прерываний? Существуют ли сценарии, в которых оба могут быть использованы?

Answer 1

Если событие представляет интерес:

1. Асинхронный
2. Срочное
3. Infrequent

тогда обработчик прерываний на основе будет иметь смысл.

Если событие представляет интерес:

1. Synchronous (т.е. вы знаете, когда следует ожидать его в небольшом окне)
2. Не Срочное (т.е. медленный интервал опроса не имеет каких-либо негативных последствий)
3. Частые (т. Е. Большинство ваших циклов опроса создают «хит»)

тогда опрос может быть лучше подходит.

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

Answer 2

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

Answer 3

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

Answer 4

В принципе, режим опроса используется в случае, если режим прерывания недоступен из-за некоторых аппаратных или программных соображений. Таким образом, режим прерывания более предпочтителен с точки зрения энергопотребления, производительности и т. Д. (Согласен с Полом R). Режим опроса также может использоваться при прототипировании, для ядер, не требующих периферии, и для некоторых целей тестирования.

Answer 5

Иногда вам действительно нужно использовать оба варианта. Например, если события являются спорадическими, но приходят с высокой скоростью всплеска; вам может потребоваться сначала ответить на прерывание, а затем перед повторным включением опроса прерываний, чтобы увидеть, произошло ли еще одно событие, избегая некоторых из-за чрезмерных затрат на переключение контекста прерывания. Я считаю, что в этом режиме работает сетевой интерфейс Linux.

Answer 6

Прерывания предпочтительнее, когда требуется низкая латентность. Если вы опросите какое-то условие N раз в секунду, то в среднем вы обнаружите это условие во время одной половины 1/N после того, как оно действительно произошло.

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

Answer 7

Всегда используйте прерывание. Таким образом, вы никогда не теряете данные.В управляемых событиях или потоках приложениях даже самые медленные сигналы должны прерываться.

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

Answer 8

Режим опроса может быть полезен в системах с высокочастотными событиями, где служебные данные, связанные с входом и выходом обработчиков прерываний, используют больше циклов ЦП, чем просто опрос. Например, опрос может использоваться в IP-маршрутизаторе, чтобы максимизировать пропускную способность ЦП, доступную для обработки пакетов.

Answer 9

При принятии решения о опросе или прерывании вам необходимо полностью понять природу события, которое вы пытаетесь выполнить, и ваш ответ на него.

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

В этом примере обработчик прерываний реагирует на лазерный луч, став ясным и устанавливает себя на событие, где он блокируется:

BEAM_INTR_EN = TRUE; /*re-enable the beam interrupts*/ 

    /*Set the beam interrupt for the next clear to blocked event*/ 
    BEAM_INTR_EDGE = CLEAR_TO_BLOCKED; 
    BEAM_INTR_FLAG = FALSE; /*Clear the interrupt*/ 

Есть 2 слабые точки этого кода: 1) Если лазерный луч снова заблокирован, прежде чем флаг прерывания будет очищен (BEAM_INTR_FLAG = FALSE;). Прерывание будет пропущено, и код будет не синхронизирован с состоянием лазерного луча.

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

Самый простой способ исправить 1) заключается в двойной проверке после того, как вы настроили прерывание, если оно произошло, а затем принудительно прервите. Чтобы исправить 2) переместить включение прерываний в после двойной проверки:

/*Set the beam interrupt for the next clear to blocked event*/ 
    BEAM_INTR_EDGE = CLEAR_TO_BLOCKED; 
    BEAM_INTR_FLAG = FALSE; /*Clear the interrupt*/ 

    /*Double check beam state to see if it has already gone blocked*/ 
    if (BEAM_STATE == BEAM_BLOCKED) 
    { 
     BEAM_INTR_FLAG = TRUE; /*Force the interrupt to re-enter the ISR after exiting*/ 
    } 
    BEAM_INTR_EN = TRUE; /*re-enable the beam interrupts*/ 

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

В основном:

Set the edge to detect the next interrupt event 
    Clear the interrupt flag 
    if (the event has already occurred) 
    { 
     Set the interrupt flag to force the interrupt 
    } 
    Enable the interrupt 

Если время отклика на события должен быть последовательным (например, 1 мс +/- 10 мкс после того, как после того, как входная линия переходит на высокий уровень, передает сигнал события), то прерывания обычно лучше всего.

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

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

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

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

Если событие не имеет критического момента и потенциально шумно (например, кто-то нажал на переключатель), то опрос позволяет простую фильтрацию без простоя долгосрочных переходов. Распространенной ошибкой является опрос несколько раз при настройке вещи:

void fnInitialiseSystem(void) 
{ 
    if (MODE_INPUT == MODE_A) /*First polling of the MODE_INPUT*/ 
    { 
     PR2 = PR2_MODE_A; 
    } 
    else 
    { 
     PR2 = PR2_MODE_B; 
    } 
    OpenTimer2(TIMER_INT_ON & 
       T2_PS_1_1  & 
       T2_POST_1_8 ); 

    if (MODE_INPUT == MODE_A) /*Second polling of the MODE_INPUT*/ 
    { 
     CurrentMode = MODE_A; 
     PROBE_INT_EDGE = CLEAR_TO_BLOCKED; 
    } 
    else 
    { 
     CurrentMode = MODE_B; 
     PROBE_INT_EDGE = BLOCKED_TO_CLEAR; 
    } 
} 

В приведенном выше примере MODE_INPUT внешний переключатель, если два раза MODE_INPUT в Опрошенные тогда отличаются поведение является неожиданным. При чтении этих сигналов лучше всего использовать фильтрацию, чтобы определить долгосрочное состояние ввода и выполнить действия в отфильтрованной версии.

Например, если переключатель отключен, просто проверьте коммутатор регулярно (каждые 1 мс) и если несколько из них (скажем, 16) различны (переключатель закрыт) из отфильтрованной версии (переключатель открыт), то обновите результат и выполните требуемое действие. Будьте осторожны с сигнальным сглаживанием, осциллирующий сигнал может выглядеть стабильным!

Примером использования опроса и прерываний является, опять же, использование ввода, который не изменяется часто, но шумно, когда он это делает. Тем не менее, опять же, это хороший пример: код может настроить прерывание, чтобы проверить изменение состояния коммутатора, когда происходит прерывание, тогда коммутатор может регулярно проверяться до тех пор, пока состояние коммутатора не станет «стабильным» (либо изменено государство или обратно к тому, что это было). Это дает преимущество низких производственных издержек, когда ничего не происходит, и фильтрации шума, когда что-то происходит.

Answer 10

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

• Внешние и внутренние источники синхронизации вызвать прерывание - это очень важно, чтобы метки времени и метко таким образом мы можем синхронизировать их.
• Входящие последовательные сообщения вызывают прерывания. Получение FIFO должно обслуживаться до переполнения.
• Исходящие сообщения вызывают прерывания, когда FIFO частично пуст - он должен быть перезаполнен до того, как он будет затерян.
• Семафоры ISR, заданные в фоновом режиме. Это имеет 2 преимущества:
  • Расчет, необходимый для обработки входящих событий, может быть длительным; если бы он остался в ISR, он мог бы задержать другие ISR за пределы их срока службы.
  • События могут быть секвенированы. Например, цикл опроса может гарантировать, что вычисление X всегда происходит между сбором данных АЦП и анализом входящих сообщений, даже если иногда сообщение приходит немного раньше, чем ожидалось.

Answer 11

Вот несколько интересных ссылок, которые я наткнулся при анализе опроса против методов прерывания - http://web.engr.oregonstate.edu/~traylor/ece473/lectures/interrupts.pdf - Очень интересной ссылки http://www.atarimagazines.com/compute/issue149/60_Interrupts_made_easy.php
http://www.electro-tech-online.com/micro-controllers/8440-interrupt-vs-polling.html http://www.microchip.com/forums/m397196-print.aspx http://www.cs.huji.ac.il/course/2006/67630/Lectures/interrupts.pdf http://sunsite.nus.edu.sg/LDP/LDP/tlk/node86.html

Надеется, что это полезно.

Answer 12

Вы не хотите, чтобы ваш хост ожидал в занятом цикле в течение длительного времени, а также опрос может стать неэффективным, если часто делаются частые проверки данных, которых часто нет. Таким образом, там, если хост и устройство работают быстро, тогда опрос будет довольно быстрым.

Answer 13

Это гораздо лучше пойти с Interrupt based design по сравнению с polling based, поскольку опрос на основе несовершенна в том смысле, что он ожидает, что данные, которые должны быть возвращены при каждом опросе. Теперь вы можете сказать, что я обойду этот случай, когда один опрос вернет мне ошибку, но почему хешь тратит все циклы циклов процессора на что-то, когда он может также вернуть ошибку ?? И ожидать, что опрос может оказаться неудачным, - это практический сценарий продукта.

Interrupt based designs сделать еще больше смысла, когда в одном опросе имеется много уровней функций. Для меня это обычная практика: продолжаете ли вы спрашивать (опрос) ваш друг снова & снова каждый день, имеет ли он информацию, в которой вы нуждаетесь, или просто скажите ему, что interrupt меня, когда у вас есть необходимая информация. Я думаю, что мы поступаем правильно в повседневной жизни, но не понимаем.

Но interrupt based architectures, когда оно реализовано, требует прочного понимания publish-subscribe design principle. И, когда это делается в доменах приложений, они требуют, чтобы часть кода, отправляющая прерывания, была действительно хорошо написана. Это хорошо, поскольку он сжимает сложность и в одном месте.

В дополнении к выше, являются следующим другими преимуществами, которые опрос на основе архитектура предоставляет вам бесплатно:

• Asynchrounous
• Подходит также в случае нечастого событий/обновления
• Update только тогда, когда существует доступные данные сценарии
• Улучшенная обработка ошибок & Управление
• Лучшее использование циклов процессора
• Лучше срок службы батареи Упр
• держит слушатель, свободные от сложности под

Всякий раз, когда вы разрабатываете sw & у вас есть этот выбор, вы всегда должны выбрать дизайн interrupt основанных над polling на основе, так как в конструкции на основе interrupt может заполнить для polling ситуацию с использованием слушателей, но дизайн на основе опроса никогда не сможет выполнить требование, требующее interrupt.

Ниже приводится краткая матрица сравнения:

     -INTERRUPT-  -LOOP- 
Speed     fast   slow 
Eficiency    good   poor 
CPU waste    low    high 
multitasking   yes    no 
complexity    high   low 
debugging    +/- easy  easy 
critical in time  excellent  poor 
code bloat    low impact  high impact