問題タブ [condition-variable]

pthreads を使用して自分の目的に合ったカスタマイズされたスレッドプールを作成しようとしていますが、pthreads は初めてです。私はこれらの ( POSIX スレッド プログラミングおよびLinux チュートリアル Posix スレッド) チュートリアルをオンラインで読みましたが、非常に役に立ちましたが、mutex と条件変数に関して (おそらくばかげた) 疑問がいくつかあります。

1. ミューテックスのスコープは何ですか? 一度に 1 つのスレッドだけがアクセスできるように、グローバルミューテックスはすべてのグローバル変数をロックしますか? 2 つのグローバル ミューテックスがある場合、それらは同じ変数セットをロックしますか? クラスまたは関数内で宣言されたミューテックスはどうなりますか? ロック/ロック解除するとどうなりますか?
2. グローバル変数を読み取るだけで、まったく変更しない場合でも、mutex ロックを使用する必要がありますか?
3. 私が正しければ、条件変数を使用してpthread_cond_wait()、何らかの条件でスリープしている (または を使用してブロックされている) 他のスレッドをウェイクアップします。スリープ状態のスレッドへのウェイクアップ コールは、他のスレッドによって、pthread_cond_signal()またはpthread_cond_broadcast()他のスレッドから与えられます。すべてまたは 1 つのスレッドがウェイクアップして作業を行い、次の作業が利用可能になるまで待機するように、制御の流れはどのように発生するはずですか? 4 つのスレッドを使用するシナリオに特に関心があります。
4. スレッドを作成する前に、スレッドのアフィニティを特定のプロセッサ コアに設定する方法はありますか (目的のコアで実行を開始し、作成後にコアの移動が発生しないようにするため)。

質問がばかげているように見える場合は申し訳ありませんが、私が言ったように、私はこれに慣れていません。ヘルプ、コメント、コード、または適切なリソースへのポインターを歓迎します。よろしくお願いします。

私はC++11の同時実行性について学んでいます。同時実行性プリミティブに関する私の唯一の以前の経験は、6年前のオペレーティングシステムクラスでした。できれば、穏やかにしてください。

C ++ 11では、次のように書くことができます

cv.waitこれは問題なく機能しますが、ループでラップする必要があることに腹を立てています。ループが必要な理由は私には明らかです。

さて、私unique_lockはそれについてのクールなことの1つは、私たちがそれを回すことができるということだと思いますよね？したがって、代わりにこれを行うことができれば、本当にエレガントになります。

ミューテックスはからI MADE YOU A COOKIEまでずっとロックされたままなので、Vultureスレッドが急降下する方法はありませんYUM。さらに、notify()ロックを渡す必要がある場合は、呼び出す前に実際にミューテックスをロックすることを確認するのに適した方法です（条件変数（pthread）のシグナリングnotify()を参照）。

C++11にはこのイディオムの標準的な実装がないことは間違いありません。その歴史的な理由は何ですか（pthreadがそれをしなかったというだけですか？そしてそれはなぜですか）？冒険的なC++コーダーがこのイディオムを標準のC++11で実装できなかったという技術的な理由はありmy_better_condition_variableますか？

また、セマフォを作り直しているのではないかと漠然と感じていますが、それが正しいかどうかを学校で十分に覚えていません。

ここから: https://computing.llnl.gov/tutorials/pthreads/#ConVarSignal

pthread_cond_wait ルーチンは、待機中にミューテックスを自動的かつアトミックにロック解除することに注意してください。

次のサブコードは同じリンクからのものです（私がフォーマットしています）：

質問:待機中にミューテックスが自動的にロック解除される
と書かれている場合、上記のコードの最後で関数を明示的に指定する必要があるのはなぜですか?pthread_cond_waitpthread_mutex_unlock

私が見逃しているポイントは何ですか？

条件変数を使用する状況を把握するために、Google を 2 時間近く検索しました。しかし、私は理解するのがより困難ないらいらさせるコードスニペットの束に他なりません。したがって、これに関する明確な概念が必要です。

thread2からの条件を待機しているthread1があります。ただし、thread2が条件変数を通知していない可能性があります。そこでwait、スレッド1の呼び出しに次のようにタイムアウトを追加しました。

条件変数が通知されたか、タイムアウトが発生したかをどのように知ることができますか？wait値を返さないようです。条件オブジェクトに関するPythonのドキュメントには、これに関する手がかりはありません。

I haven't wrapped my head around the C++11 multithreading stuff yet, but I'm trying to have multiple threads wait until some event on the main thread and then all continue at once (processing what happened), and wait again when they're done processing... looping until they're shut down. Below isn't exactly that - it's a simpler reproduction of my problem:

This works... unless I stop on some breakpoints and slow things down. When I do that I see Go1! and then hang, waiting for thread2's cv.wait. What wrong?

Maybe I shouldn't be using a condition variable anyway... there isn't any condition around the wait, nor is there data that needs protecting with a mutex. What should I do instead?

次のコードを実行するスレッド 1 があります。

そして、このコードを実行するスレッド 2:

残念ながら、私はタイミングの問題にぶつかっています:

スレッド 1 は通知を完全に逃し、wait() でブロックされたままになります。述語を使用するバージョンの wait() を使用してみましたが、基本的に同じ結果が得られました。つまり、述語の本体でチェックが実行されますが、返される前に条件の値が変更され、通知が送信されます。その後、述語が返されます。

どうすればこれを修正できますか?

プロデューサーとコンシューマー (「クライアント」) がブロードキャスト メッセージを相互に送信したい、つまりn:m関係があるアプリケーションがあります。すべてが異なるプログラムである可能性があるため、それらは異なるプロセスであり、スレッドではありません。

より保守しやすいものに減らすためにn:m、小さな中央サーバーを導入するようなセットアップを考えていました。そのサーバーは、各クライアントが接続するソケットを提供します。
そして、各クライアントはそのソケットを介してサーバーに新しいメッセージを送信し、1:n.

サーバーは、クライアントに対して読み取り専用の共有メモリも提供します。これは、サーバーによって新しいメッセージが追加され、古いメッセージが上書きされるリング バッファーとして編成されます。 これにより、クライアントがメッセージを処理する時間が与えられますが、遅すぎる場合は不運であり、いずれにせよ関係がなくなります...

このアプローチの利点は、同期だけでなく、不要なデータのコピーやバッファ階層を回避できることです。中心的なもので十分なのではないでしょうか?

それがこれまでのアーキテクチャです - 理にかなっているといいのですが...

次に、それを実装することのより興味深い側面について説明します。
リング バッファー内の最新の要素のインデックスは共有メモリ内の変数であり、クライアントはそれが変更されるまで待つ必要があります。愚かなのではなくwhile( central_index == my_last_processed_index ) { /* do nothing */ }、たとえばを使用してCPUリソースを解放したいpthread_cond_wait().

しかし、それには必要ないと思うミューテックスが必要です-一方で、なぜpthreadの条件変数関数にはミューテックスが必要なのですか? 私のアーキテクチャが理にかなっており、そのように実装できるかどうかを尋ねたほうがよいという印象を受けました...

それがすべて理にかなっており、うまくいくかどうか、ヒントを教えてもらえますか?

(補足: クライアント プログラムは、Perl や Python などの一般的なスクリプト言語で作成することもできます。そのため、サーバーとの通信はそこで再作成する必要があるため、複雑すぎたり、独自のものであってはなりません)

アプリケーションのコンテキストは次のとおりです。

1. シングルプロセスマルチスレッドプログラムです
2. 自動化された先物取引用に設計されています。先物取引市場では、数百のアクティブな先物契約があります。各コントラクトのマーケット データはティック データと呼ばれ、Future-Exchange から 500 ミリ秒ごとにプッシュされます。各自動先物取引戦略はスレッドとして実行されます。各戦略には、異なる契約のリアルタイムの市場データが必要です。例: 戦略 A は、契約 A1、契約 A2、および契約 A3 の市場データを必要とします。ストラテジー B は、コントラクト A1、コントラクト B1、コントラクト B2 のマーケット データを必要とします。
3. このプログラムの 1 つのスレッドは、すべての契約の市場データを受信し、取引後にディスク データベースに保存できるデータ バッファーに保存する市場データ レシーバーとして実行されます。したがって、このスレッドはデータ プロデューサーとしてレビューでき、ストラテジー スレッドはデータ コンシューマーとしてレビューできます。したがって、このシナリオは単一生産者複数消費者の問題です。設計では、すべての戦略スレッドが必要なティック データを効率的に取得できるようにする必要があります。
4. 考えられる設計の 1 つは、すべてのコンシューマーが条件変数を待機し、共有ロックを取得しようとすることです。新しいティックが来ると、シングル プロデューサーは排他ロックを取得し、このティック データをデータ バッファーに保存しようとします。次に、条件変数ですべての消費者に通知します。コンシューマーは通知を受けると、データ バッファーを取得して、必要なコントラクト データが更新されているかどうかを確認します (タイムスタンプを比較します)。いいえの場合、再び条件変数を待ちます。しかし、この効率の低い設計では、新しいティック データが来るたびに、すべてのコンシューマーがデータ バッファーを起動して取得することになります (取得の過程で、データが必要かどうかに関係なく、時間がかかる場合があります)。
5. 改善された設計は次のとおりです。 グローバル変数を定義して、新しく来るティック データを格納します。新しいティック データが来ると、プロデューサーはグローバル変数を更新し、ティック データをデータ バッファーに格納してから、すべてのコンシューマーに通知します。コンシューマーは目を覚まし、グローバル変数をチェックして、ティックデータが必要かどうかを確認します (データバッファー全体を取得する必要はありません)。しかし問題は、いくつかの競合状態が存在することです。コンシューマが共有ロックを取得する前に、別の新しいティック データが来て、プロデューサが先にロックを取得し、グローバル変数を更新する場合があります。そのため、消費者は 1 つのティック データを見逃すことになります。より良いデザインはありますか？(例えば、unix ドメイン ソケットを使用してブロードキャストしますか? unix ドメイン ソケットをマルチスレッド間で適用できるかどうかはわかりません。そうであれば、共有メモリを比較した場合の効率はどうですか?)

C++11でwait_forとwait_untilがどのように機能するかを理解するためのサンプルプログラムを実装しました。

コード-

出力-

sampleFunctionは、「完了」の前に「タイムアウトが発生しました」と出力されるため、期待どおりに機能していますが、sampleFunctionCondの場合はそうではありません。wait_untilがタイムアウトしたことはわかっていますが、関数sampleFunctionCOndの実行が終了した後にメッセージを出力します。

誰かが私がこれを理解するのを手伝ってくれますか？ありがとう。