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

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

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

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

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

Ответ 1

Разница между ними - это то, что делает приложение между опросами.

Если программа проверяет устройство каждую секунду и делает что-то еще в среднем случае, если нет доступных данных (включая, возможно, просто сон, оставляя ЦПУ доступным для других), он опрос. Если программа непрерывно обследует устройство (или ресурс или что-то еще), не делая ничего между проверками, он вызывает ожидание-ожидание.

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

Ответ 2

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

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

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

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

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

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

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

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

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

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