Насколько я понимаю, вы пишете свой 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).
Бесконечные циклы и ресурсы процессора для меня загадка.
Можно ли запустить бесконечный цикл без поедания ресурсов? Скажи … если он ничего не делает, а просто зацикливается. Или просто спать (1).
Есть лучший вариант.
Вы можете просто использовать семафор, который остается заблокированным в начале цикла, и вы можете сигнализировать семафору всякий раз, когда хотите, чтобы цикл выполнялся.
Обратите внимание, что это не будет съедать никаких ресурсов.
poll
а также select
Вызовы (упомянутые в комментарии Базилием Старинкевичем) или семафор (упомянутый в ответе Алсом) — это правильные способы ожидания запросов в зависимости от обстоятельств. В операционных системах без poll
или же select
должно быть что-то подобное.
ни sleep
, YieldProcessor
ни sched_yield
правильные способы сделать это по следующим причинам.
YieldProcessor
а также sched_yield
просто переместите процесс в конец работоспособной очереди, но оставьте его работоспособным. Эффект заключается в том, что они позволяют другим процессам с таким же или более высоким приоритетом выполняться, но, когда эти процессы выполнены (или если их нет), тогда процесс, который вызвал YieldProcessor
или же sched_yield
продолжает бежать. Это вызывает две проблемы. Во-первых, процессы с более низким приоритетом по-прежнему не будут выполняться. Другое — это то, что процессор всегда работает, используя энергию. Мы бы предпочли, чтобы операционная система распознавала, когда не нужно было запускать какой-либо процесс, и переводила процессор в состояние с низким энергопотреблением.
sleep
может разрешить это состояние с низким энергопотреблением, но он играет в догадки о том, сколько времени пройдет, пока не поступит следующий запрос, он несколько раз будит процессор, когда в этом нет необходимости, и делает процесс менее отзывчивым на запросы, поскольку Процесс продолжит спать до истечения запрошенного времени, даже если есть запрос на обслуживание.
poll
а также select
звонки рассчитаны именно на эту ситуацию. Они сообщают операционной системе, что этот процесс хочет обслуживать запрос, поступающий по одному из каналов ввода-вывода, но в остальном не имеет работы. Это позволяет операционной системе помечать процесс как неработоспособный и переводить процессор в состояние пониженного энергопотребления, если это необходимо.
Использование семафора обеспечивает такое же поведение, за исключением того, что сигнал для пробуждения процесса поступает от другого процесса, поднимающего семафор вместо активности, возникающей в канале ввода / вывода. Семафоры подходят, когда сигнал для выполнения некоторой работы поступает таким образом; просто используйте любой из poll
или семафор больше подходит для вашей ситуации.
Критика, что poll
, select
или семафор приводит к тому, что вызов режима ядра не имеет значения, потому что другие методы также вызывают вызовы режима ядра. Процесс не может спать самостоятельно; он должен вызвать операционную систему, чтобы запросить его. Так же, YieldProcessor
а также sched_yield
делать запросы к операционной системе.
Короткий ответ — да — удаление сна дает 100% CPU — но ответ зависит от некоторых дополнительных деталей. Он потребляет весь процессор, который он может получить, если только …
РЕДАКТИРОВАТЬ : Для вашего сценария я поддерживаю предложение, сделанное @Als.
РЕДАКТИРОВАТЬ 2: Я ожидаю, что этот ответ получил -1, потому что я утверждаю, что блокирующие операции могут быть хорошей идеей. [Если вам -1, вы должны оставить мотивацию в комментарии, чтобы мы все могли чему-то научиться.]
В настоящее время популярно мнение, что неблокированный (основанный на событиях) ввод-вывод хорош, а блокирование — плохо. Это представление упрощено, поскольку предполагает, что все программное обеспечение, которое выполняет ввод-вывод, может улучшить пропускную способность с помощью неблокирующих операций.
Какие? Я действительно предполагаю, что использование неблокирующего ввода-вывода может реально снизить пропускную способность? Да, оно может. Когда процесс выполняет одно действие, на самом деле лучше использовать блокировку ввода-вывода, потому что блокировка ввода-вывода сжигает только те ресурсы, которые уже были оплачены за время существования процесса.
Напротив, неблокирующий ввод-вывод может нести большие фиксированные издержки, чем простой блокирующий ввод-вывод. Если процесс не может предоставить дополнительные операции ввода-вывода, которые можно чередовать, то ничего не получится, заплатив за неблокирующую настройку. (На практике наибольшая стоимость неадекватного неблокирующего ввода-вывода заключается просто в дополнительной сложности кода. Кроме того, эта тема в значительной степени продуманна.)
При блокировке ввода-вывода мы полагаемся на операционную систему для планирования тех процессов, которые могут прогрессировать. Это то, для чего предназначена ОС.
При неблокирующем вводе-выводе у нас большие затраты на настройку, но мы можем распределять ресурсы процесса и его потоков между чередованной работой. Неблокирующая операция ввода-вывода идеально подходит для любого процесса, выполняющего несколько независимых операций, например для веб-сервера. Полученная пропускная способность значительно превосходит постоянные издержки неблокирующих операций ввода-вывода.