web-dev-qa-db-ja.com

無限のWhileループはCPUリソースを消費しますか？

私が理解していることから、あなたは無限ループでリクエストをリッスンする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.スリープを解除した場合、CPU消費量が100％増加するということですか？

3.リソースを消費せずに無限ループを実行することは可能ですか？言う..それが何もしない場合は、それ自体をループするだけです。または単にsleep（1）。

無限ループとCPUリソースは私には謎です。

c++clinuxdaemon
23
resting

リソースを消費せずに無限ループを実行することは可能ですか？たとえば、ループするだけの場合、または単にsleep（1）

より良いオプションがあります。
semaphoreを使用するだけで、ループの開始時にブロックされたままになり、ループを実行するときにいつでもセマフォに信号を送ることができます。
これはリソースを消費しないことに注意してください。

14
Alok Save

pollおよびselect呼び出し（Basile Starynkevitchがコメントで言及）またはセマフォ（Alsが回答で言及）は、状況に応じて、要求を待機する正しい方法です。 pollまたはselectのないオペレーティングシステムでは、同様のものがあるはずです。

以下の理由により、sleep、YieldProcessor、またはsched_yieldのいずれもこれを行う適切な方法ではありません。

YieldProcessorおよびsched_yieldは、プロセスを実行可能キューの最後に移動するだけで、実行可能のままにします。その結果、同じかそれ以上の優先度の他のプロセスを実行できますが、それらのプロセスが完了すると（またはない場合）、YieldProcessorまたはsched_yieldを呼び出したプロセスは続行されます走る。これは2つの問題を引き起こします。 1つは、優先度の低いプロセスはまだ実行されないということです。もう1つは、これにより、プロセッサが常にエネルギーを使用して実行されるようになることです。オペレーティングシステムは、プロセスを実行する必要がないことを認識し、プロセッサを低電力状態にすることをお勧めします。

sleepはこの低電力状態を許可する場合がありますが、次の要求が着信するまでの時間について推測ゲームを実行し、必要がないときにプロセッサを繰り返しウェイクアップし、プロセスを少なくします。サービスするリクエストがあったとしても、プロセスはリクエストされた時間の満了までスリープし続けるため、リクエストに応答します。

pollおよびselect呼び出しは、まさにこの状況のた​​めに設計されています。これらは、このプロセスがI/Oチャネルの1つから入ってくる要求を処理したいが、それ以外の場合は何もする必要がないことをオペレーティングシステムに伝えます。これにより、オペレーティングシステムはプロセスを実行不可としてマークし、必要に応じてプロセッサを低電力状態にすることができます。

セマフォを使用すると、プロセスをウェイクアップする信号が、I/Oチャネルで発生するアクティビティではなく、セマフォを発生させる別のプロセスから送信されることを除いて、同じ動作が提供されます。セマフォは、何らかの作業を行うための信号がこのように到着した場合に適しています。 pollまたはセマフォのどちらかが状況に適している方を使用してください。

poll、select、またはセマフォがカーネルモード呼び出しを引き起こすという批判は関係ありません。他のメソッドもカーネルモード呼び出しを引き起こすからです。プロセスはそれ自体でスリープすることはできません。それを要求するには、オペレーティングシステムを呼び出す必要があります。同様に、YieldProcessorとsched_yieldはオペレーティングシステムにリクエストを送信します。

13
Eric Postpischil

簡単な答えは「はい」です。スリープを解除するとCPUが100％になりますが、答えはいくつかの追加の詳細に依存します。それはそれが得ることができるすべてのCPUを消費します。

  1. ループ本体は簡単で、最適化されています。
  2. ループには、ブロッキング操作（ファイルやネットワーク操作など）が含まれています。あなたが提供するリンクはこれを避けることを示唆していますが、何か関連することが起こるまでブロックすることはしばしば良い考えです。

編集：あなたのシナリオでは、@ Alsによる提案をサポートします。

編集2：ブロック操作は実際には良い考えであると私は主張しているので、この回答は-1を受け取っていると思います。 [-1の場合、私たち全員が何かを学ぶことができるように、コメントに動機を残す必要があります。]

現在の一般的な考え方は、非ブロック（イベントベース）IOは良く、ブロッキングは悪いです。このビューは、IOを実行するすべてのソフトウェアを想定しているため、単純化されすぎています。 =非ブロッキング操作を使用することでスループットを向上させることができます。

何ですか？ノンブロッキングを使用するとIOは実際にスループットを低下させる可能性があることを本当に示唆していますか？はい、可能です。プロセスは単一のアクティビティを提供します。ブロッキングIOは、プロセスの存在下ですでに支払われたリソースのみを書き込むため、実際にはブロッキングIOを使用することをお勧めします。

対照的に、非ブロッキングIOは、単純なブロッキングIOよりも大きな固定オーバーヘッドを運ぶ可能性があります。プロセスが追加のIOを提供できない場合、インターリーブされている場合、非ブロッキング設定にお金を払っても何も得られません（実際には、不適切な非ブロッキングIOの最大のコストは、単に追加されたコードの複雑さにあります。それを超えて、このトピック主に思考の練習です。）

ブロッキングIO）の下で、進行する可能性のあるプロセスをスケジュールするためにオペレーティングシステムに依存しています。これがOSの設計です。

非ブロッキングIOの場合、セットアップコストは高くなりますが、インターリーブされた作業間でプロセスとそのスレッドのリソースを共有できます。非ブロッキングIOは、そのためです。 Webサーバーなど、複数の独立したアクティビティを提供するプロセスに最適です。得られるスループットは、非ブロッキングIOの固定コストオーバーヘッドよりもはるかに優れています。

3
Kevin A. Naudé