Бесконечный цикл while занимает ресурсы процессора?

Насколько я понимаю, вы пишете свой Linux-демон, который слушает запрос в бесконечном цикле.
Что-то вроде..

int main() {
while(1) {
//do something...
}
}

ссылка: http://www.thegeekstuff.com/2012/02/c-daemon-process/

Я читал, что сон программы переводит ее в режим ожидания, поэтому она не поглощает ресурсы.

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

int main() {
while(1) {
if (request) {
//do something...
}
sleep(1)
}
}

2. Если мне пришлось убрать сон, значит ли это, что загрузка процессора увеличится на 100%?

3. Можно ли запустить бесконечный цикл без использования ресурсов? Скажи … если он ничего не делает, а просто зацикливается. Или просто спать (1).

Бесконечные циклы и ресурсы процессора для меня загадка.

20

Решение

Можно ли запустить бесконечный цикл без поедания ресурсов? Скажи … если он ничего не делает, а просто зацикливается. Или просто спать (1).

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

13

Другие решения

poll а также select Вызовы (упомянутые в комментарии Базилием Старинкевичем) или семафор (упомянутый в ответе Алсом) — это правильные способы ожидания запросов в зависимости от обстоятельств. В операционных системах без poll или же selectдолжно быть что-то подобное.

ни sleep, YieldProcessorни sched_yield правильные способы сделать это по следующим причинам.

YieldProcessor а также sched_yield просто переместите процесс в конец работоспособной очереди, но оставьте его работоспособным. Эффект заключается в том, что они позволяют другим процессам с таким же или более высоким приоритетом выполняться, но, когда эти процессы выполнены (или если их нет), тогда процесс, который вызвал YieldProcessor или же sched_yield продолжает бежать. Это вызывает две проблемы. Во-первых, процессы с более низким приоритетом по-прежнему не будут выполняться. Другое — это то, что процессор всегда работает, используя энергию. Мы бы предпочли, чтобы операционная система распознавала, когда не нужно было запускать какой-либо процесс, и переводила процессор в состояние с низким энергопотреблением.

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

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

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

Критика, что poll, selectили семафор приводит к тому, что вызов режима ядра не имеет значения, потому что другие методы также вызывают вызовы режима ядра. Процесс не может спать самостоятельно; он должен вызвать операционную систему, чтобы запросить его. Так же, YieldProcessor а также sched_yield делать запросы к операционной системе.

13

Короткий ответ — да — удаление сна дает 100% CPU — но ответ зависит от некоторых дополнительных деталей. Он потребляет весь процессор, который он может получить, если только …

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

РЕДАКТИРОВАТЬ : Для вашего сценария я поддерживаю предложение, сделанное @Als.

РЕДАКТИРОВАТЬ 2: Я ожидаю, что этот ответ получил -1, потому что я утверждаю, что блокирующие операции могут быть хорошей идеей. [Если вам -1, вы должны оставить мотивацию в комментарии, чтобы мы все могли чему-то научиться.]

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

Какие? Я действительно предполагаю, что использование неблокирующего ввода-вывода может реально снизить пропускную способность? Да, оно может. Когда процесс выполняет одно действие, на самом деле лучше использовать блокировку ввода-вывода, потому что блокировка ввода-вывода сжигает только те ресурсы, которые уже были оплачены за время существования процесса.

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

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

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

2
По вопросам рекламы ammmcru@yandex.ru
Adblock
detector