問題タブ [concurrent-programming]

コンパイラで OpenMP を有効にすると、 std ::fill、std::transformなどの STL アルゴリズム/コンテナ操作を並行して実行できますか? 現在、MSVC 2008 を使用しています。または、それを同時に行う他の方法がありますか？

ありがとう。

複数のスレッドがアイテムを入れることができるときに、複数のスレッドを使用して同時キュー内のアイテムを処理しようとしている場合、理想的な解決策は、同時データ構造で Reactive Extensions を使用することであることに気付きました。

私の元の質問は次のとおりです。

ConcurrentQueue を使用している間、並列にループしながらデキューしようとしています

したがって、項目が入れられると継続的にデキューされる LINQ (または PLINQ) クエリを持つ方法があるかどうか、私は興味があります。

n 個のプロデューサーがキューにプッシュし、限られた数のスレッドを処理できるようにこれを機能させようとしているので、データベースに過負荷をかけません。

Rx フレームワークを使用できれば、すぐに開始できると思います。100 ミリ秒以内に 100 個のアイテムが配置された場合、PLINQ クエリの一部である 20 個のスレッドがキューを介して処理されます。

私が連携しようとしている 3 つのテクノロジがあります。

1. Rx フレームワーク (リアクティブ LINQ)
2. プリング
3. System.Collections.Concurrent 構造体

分散環境と並行環境で一意のシーケンス番号を生成するための制約とトレードオフに興味があります。

これを想像してみてください:私は、あなたが尋ねるたびに一意のシーケンス番号を返すだけのシステムを持っています。このようなシステムの理想的な仕様 (制約) は次のとおりです。

• 高負荷の下で起きていてください。
• できるだけ多くの同時接続を許可します。
• 分散: 複数のマシンに負荷を分散します。
• パフォーマンス: 可能な限り高速に実行し、可能な限り多くのスループットを実現します。
• 正確性: 生成される数値は次の条件を満たしている必要があります。
  1. 繰り返さない。
  2. リクエストごとに一意である必要があります (2 つのリクエストがまったく同時に発生した場合、関係を解消する方法が必要です)。
  3. (昇順) 順番に。
  4. リクエスト間にギャップはありません: 1,2,3,4... (事実上、合計 # リクエストのカウンター)
• 耐障害性: 1 つ以上のマシン、またはすべてのマシンがダウンした場合、障害が発生する前の状態に再開できます。

明らかに、これは理想化された仕様であり、すべての制約を完全に満たすことはできません。CAP定理を参照してください。ただし、制約のさまざまな緩和についての分析をお聞きしたいと思います。どのようなタイプの問題が残り、残りの問題を解決するためにどのアルゴリズムを使用するか。たとえば、カウンター制約を取り除くと、問題ははるかに簡単になります。ギャップが許容されるため、数値範囲を分割して、それらを異なるマシンにマップするだけです。

参考文献 (論文、書籍、コード) は大歓迎です。また、既存のソフトウェア (オープン ソースかどうか) のリストも保持したいと思います。

ソフトウェア:

• Snowflake : 一意の ID 番号を大規模に生成するためのネットワーク サービスで、いくつかの単純な保証があります。
• keyspace : ID を任意の目的に使用できる、公的にアクセス可能な一意の 128 ビット ID ジェネレーター
• RFC-4122 の実装は、多くの言語で存在します。RFC 仕様は、システム間の調整の必要性を防止するため、おそらく非常に優れたベースであり、UUID は 128 ビットであり、仕様の特定のバージョンを実装するソフトウェアから ID を使用する場合、タイム コード部分が含まれています。仕分け可能 など

デフォルトでは、カメラがすでに使用されている場合、その後のカメラへの参照は失敗します。

しかし、後続の参照を読み取り専用にすることは可能ですか？それでもカメラにアクセスできますか？

Read that the following code is an example of "unsafe construction" as it allows this reference to escape. I couldn't quite get how 'this' escapes. I am pretty new to the java world. Can any one help me understand this.

次のように定義されたグリッドがありますList<List<Cell>>。「セル」は私のカスタムクラスです。私のプログラムには、グリッド上のさまざまな座標にアクセスし、「Cell」クラスのデータを変更するスレッドがいくつかあります。しかし、一度に「Cell」オブジェクトにデータを書き込むスレッドは 1 つだけです。ConcurrentBag などの並行コレクションを使用すると役立つと思いましたが、すべての並行コレクションにはアイテムを追加するか、コレクションからアイテムを削除するメソッドしかないようです。そのようなコレクション内に保持されているデータを変更するためのスレッドセーフな方法はないようです。

ここで何か不足していますか、またはそのようなコレクションを使用してそれを行う「簡単な方法」はありませんか?

今日面接に行った時、面接官は私に次の質問をしました。

再入可能性と相互排除はスレッドセーフですか? 理由を説明できますか？

私は並行プログラミングに比較的慣れていないので、答えることができませんでした..しかし、私は言った...

相互排除はスレッドセーフです。しかし、再入可能性はそうではありません。それが、再入可能ロックがある理由です。

インタビュアーは次の質問に移りましたが、別の分野でした...私はこれを台無しにしたと思います...

彼が私にこれを尋ねたとき、彼は私が何を言うことを期待していますか?

更新:これはメモリの問題のようです。3.8 Gb の Hprof ファイルは、この「ブロッキング」が発生したときに JVM がそのヒープをダンプしていたことを示していました。当社の運用チームは、サイトが応答していないことを確認し、スタック トレースを取得してからインスタンスをシャットダウンしました。ヒープダンプが完了する前にサイトをシャットダウンしたと思います。ログには、エラー/例外/問題の証拠はありませんでした。おそらく、エラー メッセージが生成される前に JVM が強制終了されたためです。

元の質問 最近、エンド ユーザーにはアプリケーションがハングするように見える状況がありました。アプリケーションを再起動する前にスタック トレースを取得したところ、驚くべき結果が得られました。527 スレッドのうち、463 スレッドの状態が BLOCKED でした。

過去 過去 に、ブロックされたスレッドには通常、次の問題がありました。2) ブロックされたスレッドはすべて、同じクラス/メソッド (jdbc またはファイル システム クラスなど) でブロックされます。

異常なデータ この場合、アプリケーション クラス (jdbc および lucene 呼び出しを含む) に加えて、jvm 内部クラス、jboss クラス、log4j などを含む、あらゆる種類のクラス/メソッドがブロックされていることがわかります。

JVM がlog4j.Hierarchy.getLogger 、java.lang.reflect.Constructor.newInstance をブロックする原因は何ですか? 明らかに「不足している」リソースもありますが、どのリソースですか?

ありがとう

意思

スタック トレースの抜粋

次回の並行システム試験の準備として、教科書「マルチプロセッサプログラミングの芸術」からいくつかの質問に答えようとしています。1つの質問は私を悩ませています：

演習129： LockFreeStackオブジェクトのプッシュとポップの両方に同じ共有BackOffオブジェクトを使用することは意味がありますか？EliminationBackOffStackで、空間と時間のバックオフを他にどのように構成できますか？

この質問は私を悩ませます。最初に頭に浮かぶのは、バックオフオブジェクトが行うのはプロセスを待機させることだけなので、意味がないということです。共有してみませんか？質問の2番目の部分は完全に私を避けており、どんな助けでも大歓迎です。

LockFreeStackのコード：

以下のコードスナイパーを検討してください。

Time1スレッドThread1は、「可変」変数を更新します。ローカルキャッシュからメインメモリにメモリをフラッシュするには、setterで同期が必要です。時間Time2（Time2> Time1、スレッド競合なし）で、スレッドThread2は可変の値を読み取ります。

質問は–ゲッターの前に同期させる必要がありますか？これによって問題が発生することはないようです。メモリは最新であり、Thread2のローカルキャッシュメモリはThread1によって無効化および更新される必要がありますが、よくわかりません。