問題タブ [condition-variable]

シングル プロデューサー スレッド、シングル コンシューマー スレッドのロックレス キューがあり、プロデューサーが長期間にわたってデータを生成しない場合があるとします。キューに何もないときにコンシューマー スレッドをスリープ状態にすることは有益です (電力を節約し、他のプロセス/スレッドのために CPU を解放するため)。キューがロックレスではない場合、この問題を解決する簡単な方法は、生成スレッドにミューテックスをロックさせ、その作業を実行させ、条件変数を通知してロックを解除し、読み取りスレッドがミューテックスをロックするまで条件変数を待機することです。 、その読み取りを行い、ロックを解除します。しかし、ロックレス キューを使用している場合、まったく同じ方法でミューテックスを使用すると、そもそもロックレス キューを使用することで得られるパフォーマンスが失われてしまいます。

単純な解決策は、キューへの挿入ごとにプロデューサーにミューテックスをロックさせ、条件変数を通知してからミューテックスのロックを解除し、実際の作業 (キューへの挿入) を完全にロックの外に保ち、コンシューマーに実行させることです。同じように、ミューテックスをロックし、条件変数を待機し、ロックを解除し、キューからすべてを取り出してから繰り返し、キューの読み取りをロックの外に保ちます。ただし、ここには競合状態があります。リーダーがキューから離れてからスリープ状態になるまでの間に、プロデューサーがアイテムをキューに挿入した可能性があります。これでリーダーはスリープ状態になり、プロデューサーが別のアイテムを挿入して条件変数に再度シグナルを送るまで、無期限にスリープ状態になる可能性があります。これは、特定のアイテムがキューを通過するのに非常に長い時間がかかるように見える場合があることを意味します. キューが常にアクティブである場合、これは問題にならない可能性がありますが、常にアクティブである場合は、条件変数を完全に忘れてしまう可能性があります。

AFAICT解決策は、プロデューサーが通常のニーズロックキューを使用しているかのように動作することです。ミューテックスをロックし、ロックレス キューに挿入し、条件変数を通知し、ロックを解除する必要があります。ただし、消費者は異なる行動を取る必要があります。起動すると、キューが読み取られるまで待機するのではなく、すぐにミューテックスのロックを解除する必要があります。次に、できる限り多くのキューをプルして処理する必要があります。最後に、消費者がスリープ状態になることを考えている場合にのみ、ミューテックスをロックし、データがあるかどうかを確認し、データがある場合はロックを解除して処理するか、そうでない場合は条件変数を待機します。この方法では、ロックフル キューよりもミューテックスの競合が少なくなりますが、キューにデータが残ったままスリープ状態になるリスクはありません。

これが最善の方法ですか？代替手段はありますか？

注: 「最速」とは、実際には「キューを何度もチェックするためにコアを専用にすることなく最速」を意味しますが、それはタイトルには当てはまりません;p

1 つの代替方法: 単純なソリューションを使用しますが、キューを通過するアイテムに対して許容できる最大待機時間に対応するタイムアウトを使用して、コンシューマーを条件変数で待機させます。ただし、必要なタイムアウトがかなり短い場合は、OS の最小待機時間を下回っているか、CPU の消費量が多すぎる可能性があります。

期間のあるで使用timed_waitするboost::condition_variable場合、ユーザー（またはntp）がシステム時刻を変更しても、待機条件は期間の後にタイムアウトしますか？

例えば、

pthread_cond_signalを呼び出す前にミューテックスをロックし、呼び出し後にミューテックスをロック解除する必要があることをどこかで読みました。

pthread_cond_signal() ルーチンは、条件変数を待機している別のスレッドにシグナルを送る (またはウェイクアップする) ために使用されます。これはミューテックスがロックされた後に呼び出され、pthread_cond_wait() ルーチンが完了するためにミューテックスのロックを解除する必要があります。

私の質問は、ミューテックスをロックせずにpthread_cond_signalまたはpthread_cond_broadcastメソッドを呼び出しても問題ないのでしょうか?

次のコードはエラーを再現します。

私のシステムでは、Visual Studio2005とBoost1.43を使用すると、次の出力が生成されます。

条件変数が永遠に通知されるのを待って、デッドロックすることを期待します。timed_waitこれはどこにも文書化されていないようです。また、有効なを受け入れることを期待していますptime。私は何か間違ったことをしていますか？これはバグですか、それとも無限のタイムアウトは意図されていませんか？

条件変数「cond」がミューテックス変数「mutex」に関連付けられているとします。condを呼び出した後にスレッドがスリープ状態で、ロックされpthread_cond_wait(&cond,&mutex)ている別のスレッドが終了した場合、そのスレッドが を呼び出す前または後に呼び出すかどうかは重要ですか? とにかくスリープ状態のスレッドがミューテックスを取得するため、 を呼び出した場合、ミューテックスのロックを解除する必要さえありますか?mutexpthread_cond_signal(&cond)pthread_mutex_unlock(&mutex)pthread_cond_signal(&cond)

編集: https://computing.llnl.gov/tutorials/pthreads/#ConVarOverviewによると、「 pthread_cond_signal() を呼び出した後にミューテックスのロックを解除できないと、一致する pthread_cond_wait() ルーチンを完了できない場合があります (ブロックされたままになります)。 " その場合、ロック解除が必要になると思いますが、おそらく後でのみ必要です。

WinNT v6.x 以降でスレッドを同期するために、新しい条件変数プリミティブまたは Windows イベントのいずれかを使用できます。次の 2 つのアプローチを検討してください。main で「go」が設定されている場合はワーカーを同時に実行する必要があります。それ以外の場合は、すべてブロックする必要があります。

また

最初のアプローチでは、ワーカーは SleepConditionVariableSRW でブロックされ、WakeAllConditionVariableで起動されます。2 つ目では、 WaitForSingleObjectでブロックされ、 SetEventによって起動されます。

オーバーヘッドに関してのみ、実際にはどちらが優れていますか? (ヒント:コンテキスト スイッチ、ロック競合、ブロッキング スレッドのオーバーヘッド)

私は最初を選びますが、正当化の欠如を感じます。

しばらく前に、さまざまな同期プリミティブを相互に実装する方法について考えていました。たとえば、pthreads ではミューテックスと条件変数を取得し、これらからセマフォを構築できます。

Windows API (または少なくとも Windows API の古いバージョン) にはミューテックスとセマフォがありますが、条件変数はありません。ミューテックスとセマフォから条件変数を構築することは可能だと思いますが、私の人生では、そうする方法が思い浮かびません。

これを行うための良い構造を知っている人はいますか？

POSIXスレッドチュートリアル https://computing.llnl.gov/tutorials/pthreads/ に、論理エラーであると書かれています。

私の質問は、なぜそれが論理的なエラーなのかということです。

私のプログラムでは、これらのシグナルを使用する必要がありますが、_cond_wait状態になるスレッドがあることを保証することはできません。テストしようとしましたが、何も起こりません。これは予期しない動作またはさらに悪い動作を引き起こす可能性がありますか？

ありがとう！

条件変数で待機操作を実行すると、すぐに返されることに気付きました。その結果、次のダミー コードを実行すると、1 つの CPU が 100% ループで使用されます。

}

cond.wait(lock)への呼び出しにより、スレッドが CPU を消費していない状態になると予想されますが、そうではありません。

では、どこに問題があるのでしょうか? 上記のコードは、ブーストのドキュメントから取得しました。

（ブースト1.44を使用しています）

ありがとう、

ギヨーム