問題タブ [busy-waiting]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c++ - セマフォのセットで効果的に待機する方法は?
マルチプロデューサーとマルチクライアント間の通信に共有メモリを備えたセマフォを使用しています。私のシステムには、「格納されたセマフォ」と「処理されたセマフォ」の 2 種類のセマフォがあります。
システムは次のように実行されます。プロデューサは継続的にデータを共有メモリに入れ、格納されたセマフォの値を増やします。コンシューマはループ内にあり、そのような格納されたセマフォを待っています。コンシューマは、プロデューサからデータを受け取った後、そのようなデータを処理し、処理されたセマフォの値を増やします。プロデューサーは、「処理されたセマフォ」を待って結果を取得します。
生産者コード:
消費者コード:
私の問題は、プロデューサーからのデータがない場合、この for ループが継続的に実行されるため、消費者コードの for ループがほぼ 100% の CPU を浪費していることです。
私の質問は、CPU 時間を無駄にしない、一連のセマフォ (SELECT、POLL、または EPOLL による待機メカニズムに似ている可能性があります) を待機する他の方法があるということです。
あなたの答えを見てください。本当にありがとう!
java - Java Puzzler: ビジー待機スレッドが機能しなくなる
これはある種の Java Puzzler で、私が偶然見つけたもので、実際には説明できません。たぶん誰かができますか?
次のプログラムは、しばらくするとハングします。2 回出力した後、80 回出力した後ということもありますが、ほとんどの場合、正しく終了する前に発生します。初めて実行しない場合は、数回実行する必要がある場合があります。
ここで、ビジーな待機ループが一般的には良い考えではないことは明らかです。しかし、これは改善ではなく、何が起こっているのかを理解することです。
フィールドが に設定されている場合、またはフィールドが に設定されているWorkerThread.setWork()
場合、すべてが期待どおりに機能するため、メモリの問題が疑われます。synchronized
WorkerThread.workToDo
volatile
しかし、なぜそれが起こっているのでしょうか?デバッグは役に立ちません。ステップスルーを開始すると、すべてが期待どおりに動作します。
説明をいただければ幸いです。
c - 特定のプロセッサ秒数で実行する C プログラムを作成するにはどうすればよいですか?
パラメータとして渡された正確な CPU 秒数で実行される C プログラムが必要です。プロセスの CPU 使用率を監視するコードをテストするには、このようなプログラムが必要です。
例:
私のプロセッサで x 秒間実行する必要があります。
c++ - ビジー待機に揮発性ブール変数を使用する
別の開発者によって書かれたいくつかのコードを読んだ後に疑問が生じたので、調査を行ったところ、Andrei Alexandrescu の記事を見つけました。彼の記事では、忙しい待機のために揮発性ブール変数を使用することが可能であると述べています (待機/ウェイクアップの最初の例を参照してください)。
私はそれがどのように機能するのか本当にわかりません。
- volatile は、操作がアトミックであることを保証しません。実際には、ブール変数への読み取り/書き込みはアトミックですが、理論はそれを保証しません。私の観点からすると、上記のコードは、std::atomic::load/store 関数を使用して、それに応じてメモリの順序付け制約を取得/解放することにより、C++11 で安全に書き直すことができます。
- 説明した例ではこの問題はありませんが、複数の書き込みがある場合、メモリの順序付けに問題が発生する可能性があります。揮発性はフェンスではなく、メモリの順序付けを強制するものではなく、コンパイラの最適化を妨げるだけです。
では、なぜ多くの人が忙しい待機に volatile bool を使用し、それは本当に移植性があるのでしょうか?
concurrency - スリープ状態ではタイムアウトしますが、ビジー待機状態ではタイムアウトしません
Go ではtime.After
、スリープ状態の関数をタイムアウトにするために使用できますが、ビジー待機中 (または動作中) の関数に対して同じことを行うことはできません。次のコードはtimed out
、1 秒後に戻り、その後ハングします。
2 番目のケースでタイムアウトが発生しないのはなぜですか? また、作業中のゴルーチンを中断するためにどのような代替手段を使用する必要がありますか?