Windows サービスのタイマーに関するこの質問により、次のように考えるようになりました。
WaitHandleで待機している Windows サービスがあるとします (そして、私はそうしています)。
ウェイトスピン図 http://www.86th.org/waitspin.jpg
タイマーを使用する方がウェイトスピンループ(スピンウェイトと呼ばれることもあります) よりも優れているかどうか興味があります。正直なところ、私はタイマーを自分のいじくり回し以外に使用したことがありません。
違いが大きく、Timer を使用するメリットが驚くべきものでない限り、切り替える予定はありません。しかし、私は、このプロジェクトの将来の発展のために、一方と他方に対する人々の考えに非常に興味があります.
これがウィキであるべきかどうか教えてください
私はあなたがタイマーから利益を得ているのを見ていません。あなたは本質的にあなたの睡眠の呼び出しでとにかくタイマーとして振る舞っています、そしてあなたは睡眠がタイムスライスを生み出すのであなたは帯域幅を占有していません。明示的なタイマーを起動して電話をかけると、コードが複雑になります。
私は一般的にスピンウェイトを眠らないものと考えているので、あなたがスピンウェイトをしているとは言いません。それは、go信号を待っているプロセッサ時間のすべてを燃やすだけです。
スレッドをスリープ状態にすることと、タイムアウトのあるハンドルを待機することは、基本的に同じことです。タイマーは本質的にスリープを使用して実装されていると思いますので、そこにも大きな違いはありません。別の言い方をすれば、個別の待機ループとスリープ ループを実装するのではなく、1 つのループでタイムアウトを使用してハンドルを待機し、待機が解放された理由 (データが利用可能かタイムアウトか) を確認することで、コードを簡素化できます。独立したループよりもわずかに効率的です。
理想的には、スリープをまったく使用せず、データ生成コードに依存して消費コードが待機しているイベントを正しく発生させ、イベント ソースがなくなったときに処理するタイムアウトを長くします。
データがソケットやその他の入力デバイスなどの外部にある場合、通常、データが使用可能になるまで待機できるようにハンドルを設定できます。その場合、データの準備ができたときにイベントが常に通知されるため、ポーリングする必要はありません。消費のために。
それは本当にあなたの要件に依存すると思います：
Timer と Thread.Sleep は両方とも実行できますが、ケース 1 では Timer が、ケース 2 では Thread.Sleep が簡単なようです。
実際、私は同様の質問 ( Windows サービスのスケジュールされた実行)に対して、より長いコメント (ケース 1 に関する考慮事項を含む) を付けました。
ポーリングは良くなく、ほとんどの場合回避できます。些細なことの場合、それを回避するために必要な複雑さよりも悪くない場合があります。
「データはありますか?」についてどのソースをポーリングしていますか? ある種のハンドル待機に変えることはできませんか？
また、Sleep()かなりの時間、深刻なコード (サービスなど) を使用しないでください。できる唯一のブロックはWaitFor[Single|Multiple]Objects(...)、プロセスをシャットダウンするときに発生するイベントがハンドルのリストに含まれている場合です。呼び出しているすべての場所を見つけてSleep(millisec)、 に置き換えますWaitForSingleObjects(g_shutdownEvent, millisec)。
糸を使用しています。それらはタイマーのように機能するだけでなく、スレッドがスリープしている間に他の操作を実行するためのハンドルを提供します。
レイモンド・チェンが説明するように、「ええ、何でも」。データの準備ができたときに通知を受け取る方法がわからない場合は、SOL.
