問題タブ [condition-variable]

誰かがboost::condition :: timed_waitを最も簡単に使用する方法の例を持っていますか？ここ、ここ、ここのトピックに関するいくつかのスレッドがありますが、実際の例を備えたスレッドはありません。そして、ブーストドキュメントはいつものようにかなりまばらです。

Boostバージョン-1.47boost:: interprocess :: interprocess_sharable_mutexが見つかりませんが、前方宣言されているようです。これは本当にサポートされていますか？

boost :: interprocess :: interprocess_upgradable_mutexが前方宣言されており、同様に定義されていることがわかります。ただし、このミューテックスを使用できる対応する条件変数を見つけることができません。何か案は ？

モジュール内のConditionとEventクラスの違いについての明確な説明はまだ見つかりません。threading一方が他方よりも役立つという明確なユースケースはありますか？私が見つけることができるすべての例は、例として生産者/消費者モデルを使用しています。ここqueue.Queueで、より簡単な解決策になります。

pthread_cond_signalシグナリングスレッドが述語の真理値に影響を与える状態を変更し、条件変数に関連付けられたミューテックスを保持せずに呼び出す状況で条件変数が使用されると仮定しますか？このタイプの使用法は、信号が失われる可能性のある競合状態に常にさらされているというのは本当ですか？

私には、常に明らかな競争があるように思われます。

1. ウェイターは述語をfalseと評価しますが、待機を開始する前に...
2. 別のスレッドは、述語を真にする方法で状態を変更します。
3. 他のスレッドはを呼び出しますがpthread_cond_signal、ウェイターがまだいないため、何もしません。
4. ウェイタースレッドはpthread_cond_wait、述語が真であることに気付かずに入り、無期限に待機します。

pthread_cond_signalしかし、（A）状態を変更している間だけでなく、呼び出し中にミューテックスが保持されるように、または（B）状態を変更している間ミューテックスが保持されるように状況が変更された場合、これと同じ種類の競合状態が常に存在しますか？呼び出している間だけではありませんpthread_cond_signalか？

上記のベストプラクティスではない使用法の有効な使用法があるかどうか、つまり、競合状態自体を回避するために正しい条件変数の実装でそのような使用法を考慮する必要があるかどうかを知りたいという観点から質問しています。それらはすでに本質的に競合しているため、無視できます。

私は pthread 条件変数 (Linux futex に基づく) を実装しておりpthread_cond_broadcast、プロセス共有条件変数での「スタンピード効果」を回避するためのアイデアがあります。非プロセス共有条件変数の場合、futex 再キューイング操作は伝統的に (つまり NPTL によって) ウェイターを起動せずに cond 変数の futex からミューテックスの futex に再キューイングするために使用されますが、これは一般にプロセス共有条件変数では不可能です。pthread_cond_broadcast関連するミューテックスへの有効なポインターがない可能性があるためです。最悪のシナリオでは、ミューテックスがそのメモリ空間にマップされていない可能性さえあります。

この問題を克服するための私の考えはpthread_cond_broadcast、ミューテックスへの必要なポインターがあるため、ウェイターを 1 つだけ直接ウェイクし、そのウェイターがウェイクアップ時にリキュー操作を実行することです。

当然のことながら、このアプローチを追求する場合、考慮すべき多くの醜い競合状態がありますが、それらを克服できる場合、そのような実装が無効または望ましくない他の理由はありますか? 克服できないかもしれないと私が考えることができる1つの潜在的な問題は、リキューを担当するウェイター（別のプロセス）が動作する前に殺されるレースですが、condvarを配置することでこれでも克服できるかもしれません堅牢なミューテックス リストに futex を追加して、プロセスが終了したときにカーネルがウェイクを実行できるようにします。

POSIXによると、

現在ブロックされているスレッドがない初期化された条件変数を破棄しても安全です。

さらに、条件変数でブロックされた 1 つまたはすべてのスレッドのブロックを解除するために、シグナルおよびブロードキャスト操作が指定されます。

したがって、次の形式の自己同期破壊が有効であるように思われます。つまり、 を呼び出しpthread_cond_destroyます。

1. cond var.
2. 待機中のスレッドまたはブロードキャスト スレッドのいずれかで、ブロードキャストが成功した直後。

もちろん、これはそれ以上のウェイターが到着せず、その後さらにシグナルが実行されないことを前提としていますpthread_cond_destroy。

これらの状況で破壊が有効であるというのは正しいですか? また、条件変数で注意すべき他の自己同期破壊シナリオはありますか?

最後に、破棄せずに共有マッピングのマッピングを解除することが理にかなっているプロセス共有の cond 変数の場合、マッピング解除が同じコンテキストで有効であると期待するのは合理的ですか? (アドレス空間) は同じマッピングを使用しており、上記のコンテキストのいずれかでマッピングを解除したいですか?

条件変数を使用して2つのスレッド間の同期を作成する単純なプログラムを作成しました。解決策が見つからないような奇妙な出力が表示されます。

プログラムが行うことは、ジェネレータスレッドで、1000個のランダムな整数を生成し、それらが完全な平方であるかどうかを確認することです。数値が完全な平方である場合、数値の平方根を出力するモニタースレッドに信号を送ります。

私が抱えている問題は、ジェネレーターが信号を送ったときにモニターが平方根を出力しないため、ある種の競合状態である可能性があります。

奇妙な部分は、変数が変更されるたびにステップスルーするgdb bでデバッグis_squareすると、問題が存在しないことです。

任意の洞察をいただければ幸いです。私はそれが私のミューテックスまたは条件の配置に関係していると感じています。

std::condition_variable明らかな何かが欠けている可能性がありますが、との違いはわかりませんstd::condition_variable_any。なぜ両方が必要なのですか？

std::thread現在、 C++11を使用してマルチスレッド プロジェクトを実装しています。std::condition_variableスレッドを同期するために使用します。詳細には、1 つのコンシューマー関数がwait()メンバー関数を呼び出しstd::condition_variableてグローバル タスク キューからタスクを待機し、別のプロデューサー関数がタスクを生成してキューに入れます。notify_all()しかし、とのnotify_one()メンバー関数の違いがわかりませんstd::condition_variable。プロデューサー関数ではどの関数を使用すればよいですか? ありがとう！

boost::thread が初めてなので、先日 BlockingQueue を書こうとしていました (私の意見では、これまでで最も実用的な同期構造です)。これは、セマフォまたは条件変数のいずれかを使用して達成されます。以前は両方とも Windows でそれぞれ Linux で実行されていましたが、boost は使用されていませんでした。

したがって、「モニター」が利用可能な言語 (ロック、待機、および通知を備えたもの) では、次のように使用します。

私が言うことができることから、「モニター」はboost::mutexと連携してboost::condition_variable_anyを使用して達成されます。しかし、 condition_variable_any には既にミューテックスが含まれています! (internal_mutex と呼ばれます)。そのため、最初は condition_variable_any がモニター全体であると考えていましたが、結局のところ、ミューテックスは外部からアクセスできず、待機する前にロックすることはできません.

boost::condition_variable_any::internal_mutex の目的を知っている人はいますか? 私の場合、本当に混乱しました。 pthread_cond_t での待機は、ミューテックスをロックした状態で行う必要があることを知っていますが、どのミューテックスですか?? ありがとう。