26

私が理解していることから、あなたは無限ループでリクエストをリッスンする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リソースは私には謎です。

4

3 に答える 3

16

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

次の理由により、、、またはこれを行う適切な方法ではありませsleepん。YieldProcessorsched_yield

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

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

pollおよび呼び出しは、まさにこの状況のた​​めselectに設計されています。これらは、このプロセスがI / Oチャネルの1つで着信する要求を処理することを望んでいるが、それ以外の場合は実行する作業がないことをオペレーティングシステムに通知します。これにより、オペレーティングシステムはプロセスを実行不可としてマークし、適切な場合はプロセッサを低電力状態にすることができます。

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

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

于 2012-12-03T14:34:12.533 に答える
14

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

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

于 2012-12-03T09:41:36.250 に答える
3

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

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

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

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

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

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

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

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

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

于 2012-12-03T09:45:14.783 に答える