問題タブ [barrier]

この質問は以下に基づいています：

pthreadバリアを破壊するのはいつ安全ですか？

および最近のglibcバグレポート：

http://sourceware.org/bugzilla/show_bug.cgi?id=12674

pthread_barrier_waitglibcで報告されたセマフォの問題についてはよくわかりませんが、上記のリンクされた質問のように、戻ったらすぐにバリアを破棄することが有効であると思われます。（通常、取得したスレッドPTHREAD_BARRIER_SERIAL_THREAD、またはバリアオブジェクトに対してすでに「責任がある」と見なされている「特別な」スレッドは、それを破棄するスレッドになります。）私が考えることができる主なユースケースは、バリアが次のように使用される場合です。新しいスレッドによるデータの使用を作成中のスレッドのスタックで同期し、新しいスレッドがデータを使用できるようになるまで作成中のスレッドが戻らないようにします。他のバリアは、おそらくプログラム全体のライフタイムと等しいか、他の同期オブジェクトによって制御されます。

いずれにせよ、実装はどのようにしてバリアの破壊（そしておそらくそれが存在するメモリのマッピング解除さえも）がpthread_barrier_waitスレッドに戻るとすぐに安全であることを保証できますか？まだ戻っていない他のスレッドは、作業を完了して戻るためにバリアオブジェクトの少なくとも一部を調べる必要があるようです。これは、上記のglibcバグレポートで、sem_post調整後にウェイター数を調べる必要があるのと同じです。セマフォ値。

スレッドを同期するために pthread_barrier_wait を使用していますが、私のプログラムでは、他のスレッドが pthread_barrier_wait に到達するのを待っている間に、1 つ以上のスレッドが期限切れになる可能性があります。pthread_barrier_wait でスタックしているスレッドが、すべてのスレッドがバリアに達している間に一部のスレッドが期限切れになったことを知る方法はありますか?

Webアプリケーションプログラミングを理解する（そしてそれに移行する）ために、クライアントサーバープログラマーが直面する（克服しなければならない）困難について、少し光を当てていただけませんか？

Windowsフォームを作成している人が少なくとも10年間クライアントサーバーデータベースアプリケーションを形成していると考えてください。

私は現在、以前の反復で OS 試験のトレーニングを行っていますが、これに遭遇しました。

「N Process Barrier」を実装します。つまり、それらのグループの各プロセスが、それぞれの実行のある時点で、他のプロセスが特定のポイントに到達するまで待機するようにします。

次の ops を利用できます。

init(sem,value), wait(sem) and signal(sem)

N は任意の数です。特定の数のプロセスで機能するように作成できますが、任意の数では機能しません。

何か案は？疑似コードで返信しても構いません。これは課題ではなく、個人的な勉強です。

最近、いくつかの Linux カーネル空間コードを読んでいます。

このコード スニペットのセマンティクスは何ですか? ＃1が＃3の前に＃2で実行されることを確認しますか。しかし、私は少し混乱しています。

#A 64 ビット プラットフォームでは、atomic64_read マクロは次のように展開されます。

32 ビット プラットフォームでは、ロックcmpxchg8bを使用するように変換されました。これら 2 つは同じセマンティクスを持っていると仮定します。64 ビット版の場合、次の意味だと思います。

1. all-or-nothingの場合、アドレスがアラインされておらず、ワード サイズが CPU のネイティブ ワード サイズよりも大きい場合を除外できます。
2. 最適化なし、メモリ位置からの CPU 読み取りを強制します。

atomic64_read には、読み取り順序を保持するためのセマンティックがありません!!! これを見る

#Bバリアマクロは次のように定義されます。

wikiから、これはgccコンパイラが読み書きを並べ替えるのを防ぐだけです。

私が混乱しているのは、CPU の並べ替え最適化を無効にする方法です。また、バリアマクロはフルフェンスと考えていいのでしょうか？

ほとんどの条件下で、ローカル読み取りで問題なく動作するロックフリー コードをいくつか書きました。

メモリ読み取りでのローカル スピンは、スピン読み取りの前に常にメモリ バリアを挿入する必要があることを意味しますか?

（これを検証するために、特定の非常に特定の条件下で、リーダーが書き込まれた値をまったく見ないという結果になるリーダー/ライターの組み合わせを作成することに成功しました。ループ内で実行されるため、矢印はその方向を指していますが、メモリバリアを通過するコストについては完全にはわかりません.)

キャッシュのストア バッファにフラッシュするものが何もない場合、メモリ バリアを介してスピンするコストはいくらですか? つまり、すべてのプロセスが (C で) 行っているのは、

それは無料であり、メモリバスにトラフィックを邪魔しないと仮定するのは正しいですか?

別の言い方をすれば、次のように質問することです: メモリ バリアは、ストア バッファーをフラッシュし、無効化を適用し、コンパイラーがその場所全体で読み取り/書き込みを並べ替えないようにする以上のことを行いますか?

逆アセンブルすると、__sync_synchronize() は次のように変換されます。

Intelのマニュアルから（同様に、初心者にとっては漠然としています）：

私の翻訳: 「ロックと言うと、これはコストがかかりますが、必要な場合にのみ行っています。」

@BlankXavier：

ライターがストア バッファーから書き込みを明示的にプッシュアウトせず、それがその CPU で実行されている唯一のプロセスである場合、リーダーはライターの効果を確認できない可能性があることをテストしました (テスト プログラムで再現できますが、上で述べたように、特定のコンパイルオプションと専用のコア割り当てを使用した特定のテストでのみ発生します-私のアルゴリズムは正常に機能します。将来の問題）。

デフォルトでは、単純な書き込みはWB書き込み（ライトバック）であると思います。つまり、すぐにはフラッシュされませんが、読み取りは最新の値になります（「ストア転送」と呼ばれると思います）。そこで、ライタには CAS 命令を使用します。Intelのマニュアルで、これらすべての異なるタイプの書き込み実装（UC、WC、WT、WB、WP）、Intel vol 3A chap 11-10を発見し、まだそれらについて学んでいます。

私の不確実性は読者の側にあります.McKenneyの論文から、バスからキャッシュへの受信無効化のキューである無効化キューもあることがわかりました。この部分がどのように機能するかわかりません。特に、通常の読み取りをループする（つまり、ロックされていない、バリアなしで、揮発性を使用して、コンパイル後にオプティマイザーが読み取りを確実に残すようにする）と、毎回「無効化キュー」にチェックインすることを暗示しているようです。 （そのようなものが存在する場合）。単純な読み取りでは不十分な場合 (つまり、キューに入れられた無効化が保留されている間はまだ有効に見える古いキャッシュ ラインを読み取ることができます (これは私にも少し矛盾しているように聞こえますが、無効化キューはどのように機能するのでしょうか?))、アトミック読み取りは次のようになります。私の質問は次のとおりです。この場合、これはバスに影響を与えますか? （多分無いと思います。）

私はまだ Intel のマニュアルを読んでいますが、ストア フォワーディングについては素晴らしい議論が見られますが、無効化キューについては適切な議論が見つかりませんでした。C コードを ASM に変換して実験することにしました。これがどのように機能するかを実際に理解するには、これが最善の方法だと思います。

バリアを使用する単純な C# の例を作成しましたが、関数の 1 つに例外をスローしましたが、予期しない結果が得られました

コードでわかるように、DoWork1メソッドで例外をスローし、3つのメソッドすべてが例外を処理することを期待していましたが、最初のメソッドのみが例外を処理することを期待していました.2番目の問題は、最初のメソッドのみが「フェーズ3 bla bla」を出力し、3つすべてを期待したコンソールに出力します。なぜこれが起こるのか誰か説明してもらえますか

コードは少し長いですが、そのほとんどは単なるコピペです

MPI 関数の動作を理解するためにいくつかのテストを実行したところ、MPI_Barrier で奇妙な結果が得られました。

しかし、ループ内から呼び出すと、ランダムな結果が得られます。具体的には、次のテストコードがあります。

3つのタスクで実行すると、ランダムに取得されます:

これは私が期待するものです、またはちょうど反対です：

またはその間の何か、のように

MPI_Barrier とループの間に競合があるかどうか教えてもらえますか? (異なるタスクで異なるサイズのループを使用してデッドロックを回避するための警告しか見つかりませんでした。) ある場合、ループの新しい反復を開始する前にタスクを互いに待機させるにはどうすればよいですか? そうでない場合、このコードの何が問題になっていますか?

ありがとう！

何らかの理由で、.NET 3.5 に固執する必要があり、.NET 4 の Barrier クラスの機能が必要です。いくつかの作業を行うスレッドがたくさんあり、すべてが完了するまで相互に待機する必要があります。すべてが終わったら、同じように何度も何度もやってもらいたいと思います。C# 4.0 の Barrier と C# 3.0 の WaitHandle の違いというスレッドに励まされていますか? AutoResetEvent クラスと WaitHandle クラスを使用して Barrier 機能を実装することにしました。私のコードで問題が発生しましたが：

私が受け取る出力は次のとおりです。

「バリア」のスレッド 0 は 7564 の間スリープします 「バリア」のスレッド 1 は 5123 の間スリープします 「バリア」のスレッド 2 は 4237 の間スリープします 「バリア」のスレッド 2 は時間 4237 で「バリア」のスレッド 1時間 5123 で 'バリア' のスレッド 0 時間 7564 'バリア' でのスレッド 0 は 8641 時間スリープします 'バリア' でのスレッド 0 時間 8641

以上です。最後の行の後、それ以上の出力はなく、アプリは終了しません。ある種の行き詰まりがあるようです。ただし、問題が見つかりません。どんな助けでも大歓迎です。

ありがとう！

過去の質問で、私は破壊レースなしでpthreadバリアを実装することについて尋ねました：

pthread_barrier_waitが戻るとすぐに、バリアを破棄するにはどうすればよいですか？

そして、Michael Burrから、プロセスローカルバリアの完璧なソリューションを受け取りましたが、プロセス共有バリアでは失敗します。その後、いくつかのアイデアに取り組みましたが、満足のいく結論に達することはなく、リソース障害のケースにさえ入り始めませんでした。

Linuxで、次の条件を満たすバリアを作成することは可能ですか。

• プロセス共有（任意の共有メモリに作成できます）。
• バリア待機関数が戻った直後に、任意のスレッドからバリアをマップ解除または破棄しても安全です。
• リソース割り当ての失敗が原因で失敗することはありません。

プロセス共有のケースを解決しようとするMichaelの試み（リンクされた質問を参照）には、待機時に何らかのシステムリソースを割り当てる必要があるという不幸な性質があります。つまり、待機が失敗する可能性があります。そして、バリア待機が失敗したときに発信者が合理的に何ができるかは不明です。なぜなら、バリアの全体的なポイントは、残りのN-1スレッドがそれに到達するまで続行するのは安全ではないということです...

カーネルスペースソリューションが唯一の方法かもしれませんが、信号が待機を中断し、それを再開する信頼できる方法がない可能性があるため、それでも困難です...