В чем разница между занятым ожиданием и опросом?

Question

Из статьи Википедии об опросе

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

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

Итак, когда поток не использует "условные переменные", будет ли он называться "опросом" для изменения данных или "занятым ожиданием"?

Answer 1

Разница между ними заключается в том, что приложение делает между опросами.

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

Это не связано напрямую с синхронизацией. Программа, которая блокирует переменную условия (которая должна сигнализировать, когда устройство или ресурс доступны) не является ни опросом, ни ожиданием занятости. Это больше похоже на управляемый событиями / управляемый прерыванием ввод-вывод.
(Но, например, поток, который зацикливается вокруг try_lock является формой опроса, и, возможно, ожидания заняты, если цикл плотный.)

Answer 2

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

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

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

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

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

В случаях, когда требуется быстрый ответ, часто необходимо использовать либо прерывание, инициируемое событием, либо ожидание занятости. Однако во многих случаях опрашиваемый подход может быть наиболее практичным. Аппаратное обеспечение может не существовать для поддержки всех интересующих его событий, или количество интересующих его событий может существенно превышать количество доступных прерываний. Кроме того, для определенных условий может быть желательным генерировать задержанный ответ. Например, предположим, что кто-то хочет посчитать, сколько раз активируется переключатель, при условии соблюдения следующих критериев:

1. Каждое допустимое событие переключения будет состоять из интервала от 0 до 900 мкс (микросекунд), в течение которого коммутатор может произвольно замыкаться и вновь открываться, после чего следует интервал не менее 1,1 мс, в течение которого коммутатор будет оставаться замкнутым, с последующим интервалом от 0 до 900 мсек, в течение которых коммутатор может произвольно открываться и замыкаться, после чего следует интервал, по крайней мере, 1,1 мс, в течение которого коммутатор будет разомкнут.
2. Программное обеспечение должно игнорировать состояние коммутатора в течение 950 мкс после любого незамеченного открытия или закрытия коммутатора.
3. Программному обеспечению разрешено произвольно подсчитывать или игнорировать события переключения, которые происходят за пределами указанного выше необходимого интервала гашения, но длятся менее 1,1 мс.
4. Сообщаемое количество программного обеспечения должно быть действительным в течение 1,99 мс после того, как переключатель стабильно "замкнут".

Самый простой способ обеспечить соблюдение этого требования - наблюдать за состоянием коммутатора 1000 раз в секунду; если он виден "закрытым", когда предыдущее состояние было "открытым", увеличьте счетчик. Очень просто и легко; даже если выключатель открывается и закрывается всевозможными странными способами, в течение 900 мс, предшествующих реальному событию и после него, программное обеспечение не будет беспокоиться.

Можно было бы использовать прерывание, инициируемое переключателем на входе, вместе с таймером, чтобы дать более быстрый отклик на вход переключателя, одновременно удовлетворяя требуемому требованию гашения. Первоначально вход будет поставлен на охрану для запуска в следующий раз, когда переключатель замкнется. После запуска прерывания программное обеспечение отключает его, но устанавливает таймер для запуска прерывания после 950 мкс. По истечении этого таймера он запускает прерывание, которое активирует прерывание для срабатывания при следующем открытии переключателя. Это прерывание, в свою очередь, отключило бы прерывание переключателя и снова установило таймер на 950 мкс, так что прерывание таймера снова включило бы прерывание переключателя. Иногда этот подход может быть полезен, но программное обеспечение намного сложнее, чем простой опрос. Когда подход на основе таймера будет достаточным, он часто является предпочтительным.

В системах, которые используют многозадачную ОС, а не прямые прерывания, применяются многие из тех же принципов. Периодический опрос ввода-вывода будет тратить некоторое время ЦП по сравнению с наличием кода, который ОС не будет выполнять до тех пор, пока не произойдут определенные события, но во многих случаях как время отклика на событие, так и количество времени, потраченное, когда событие не происходит, будет приемлемым при использовании периодический опрос. Действительно, в некоторых ситуациях с буферизованным вводом-выводом периодический опрос может оказаться весьма эффективным. Например, предположим, что один получает большой объем данных с удаленного компьютера через последовательный порт, в секунду будет поступать не более 11520 байт, устройство будет отправлять до 2 КБ данных перед последним подтвержденным пакетом, а последовательный порт имеет входной буфер 4K. В то время как можно обрабатывать данные, используя событие "данные получены", может быть столь же эффективно просто проверить порт 100x/ сек и обработать все пакеты, полученные до этой точки. Такой опрос был бы пустой тратой времени, когда удаленное устройство не отправляло данные, но если ожидались входящие данные, возможно, было бы более эффективно обрабатывать их кусками размером примерно 1,15 Кб, чем обрабатывать каждый маленький кусочек входящих данных, как только это входит.