問題タブ [contention]

mac-802.11.h ファイルの cw_ 値を変更しようとしていますが、うまくいきません。

通常はこのようにしcw_=(cw_<<1)+1ます。

これは私が試したものですcw_=(cw_ * 1.8)+1。

上記は、シミュレーション後に平均スループットと平均パケット ドロップに関して結果に変化はありませんでした。

私は何かを逃していますか？それとも、CW 値はバイナリ形式でしか変更できないということですか。

500x500 の環境で 10 ノードを使用しています。TCL では、1 つの TCP エージェントと FTP アプリケーションが使用されます。ノードはランダムに移動しますが、TCP エージェントとシンクはシミュレーションでそれぞれのノードに接続されます。

ピーターソンの 2 プロセス アルゴリズムの競合のない複雑さは 4 です (エントリ コードで共有レジスタ メモリへの 2 つのアクセスを実行し、終了コードで 1 つのアクセスを実行します)。競合のない複雑さが 3 になるように、Peterson の 2 プロセス アルゴリズムを変更するにはどうすればよいですか? ありがとう。

システム V には、MessageQueue、SharedMemory、Semaphore の 3 つの ipc 方法があります。 2 つのプロセスが同時に読み書きする場合、スレッド ロックなどの同期を使用する必要がありますか?

そしてPOSIX IPC？

std :: map（またはstd :: set、このシナリオでは同じように動作するようです）で奇妙な動作をします。 これがどのように機能するかについて、私は重大な誤解を持っているのかもしれません。 VS2010SP1を使用しています。

この関数を例にとってみましょう。

ここで、それぞれ100,000回の反復で8つのスレッドを実行すると、g_nElapsedは約40秒になります。800,000回の反復で1つのスレッドを実行すると、g_nElapsedは約5秒になります。g_nElapsedは、妥当な量のスレッドでほぼ同じである必要があるという印象を受けています。いわば...作業は同じままですが、プロセッサの使用量はスレッドの数とともに増加します。ただし、セットとのある種のリソース競合により、ランタイムが増加するようです。しかし、なぜ？スレッドローカルです...

それは単純な誤解と単純な修正であると確信していますが、ここでの問題が何であるかはよくわかりません。

次のコードはこの動作を示しません。

シングル コア マシンは 1 つのスレッドしか実行できないという仮定から始めています。今、20 のスレッドを生成し、BigDecimal を使用して多数の階乗を計算する Java/Spring ベースの junit テストを作成しました。

Visual VM でその junit を監視したところ、20 個のスレッドすべてが動作していることを確認でき、Visual VM で実行中 (緑) として表示されます。私が理解しているように、jvm はそれらがすべて実行されているように見えますが、非常に細かいレベルでは、各スレッドが CPU サイクルを順番に処理します。すべてのスレッドが互いに干渉し、CPU があるスレッドから別のスレッドに切り替わることを視覚的または数値で証明する方法またはツールはありますか? つまり、特定の関数を実行する特定の数のスレッドについて、CPU による極端なコンテキストの切り替えによる飽和点または収益の減少を確認したいと考えています。

私が解決しなければならない実際の問題は、大規模な Java アプリケーションでスレッドを調整することです。サンプルの実行でスレッドの競合が見られない場合は、大規模なアプリケーションでもスレッドの競合や乱用を確認できません。

概要：

同じ行を更新しようとして大量のメッセージが発生し、Oracle デッドロック エラーが発生する高スループット アプリケーションのベスト プラクティスを知りたいです。これらのエラーを回避できないことはわかっていますが、何度も何度も発生するデッドロック エラーによって行き詰まることなく、どのようにして正常に回復するのでしょうか。

詳細：

高スループットの JMS メッセージング アプリケーションを構築しています。本番環境は、2 つの weblogic 11g ノード (それぞれ 6 つの MDB リスナー インスタンスを実行) になります。Oracle データベースで同じ行を更新しようとする約 1000 のメッセージを取得すると、Oracle デッドロック エラー (ORA-00060) が発生していました。ノード間の Java 同期は、標準の Java スレッド API では不可能です (テラコッタなどのサードパーティ ソリューションを使用したくない他のソリューションがない場合を除きます)。

Oracleの「select for update WAIT n secs」ステートメントが役立つことを期待していました。これにより、競合するスレッド（同じ行の）が最初のスレッド（最初に行のロックを取得したスレッド）が処理されるまで数秒待機するようになるためです。 .

「SELECT FOR UPDATE WAIT n」の最初の問題は、待機時間にミリ秒を使用できないことです。これは、アプリケーションのスループットに悪影響を及ぼし始めます。これは、1 秒の WAIT (最小待機時間) を設定するとメッセージの遅延が発生するためです。

次に、weblogic キューの再配信遅延パラメーター (この場合は 30 秒) をいじっています。デッドロック エラーが原因でスレッドが跳ね返るたびに、再試行されるまで 30 秒待機します。

私たちの経験では、1000 件の競合するメッセージがあり、デッドロックが何度も発生し続けるため、多くの状況で処理に永遠に時間がかかります。

現在のアーキテクチャでは、(1000 件の競合するメッセージの場合) 関係なくデッドロック エラーが発生するはずですが、アプリケーションは、ループ メッセージを再試行した後にこれらのエラーから回復するのに十分な回復力を備えている必要があることを理解しています。

ここで何が欠けているか分かりますか? 以前に同様の問題に対処したことがある人はいますか？

このデッドロック状態から回復し、追加のハードウェアをあまり使用せずに適切な時間内にすべてのメッセージを最終的に処理できるように、これを弾力的に機能させることができる設計のアイデアを探しています。

計算の詳細: これらの 1000 のメッセージは、それぞれに関連付けられた数量を持つ 4 つの異なるポジション タイプの 4 つのオブジェクトを作成します。これらの数量は、(ポジション タイプに応じて) 4 つの異なるスロットに統合する必要があります。これらの 4 つの個別のスロットが個別のスレッドによって更新されているときに、デッドロックが発生しています。競合状態を回避するために、データベース行に適用される前に、これらの個々の更新を特定の順序で並べ替えています。

最初に、冗長なリクエストについてお詫び申し上げます。

アクティビティがキューに入れられるまで、それぞれの WaitHandle (AutoResetEvent) で待機する多数のスレッドを備えたインフラストラクチャがあります。次の理由で、そのインフラストラクチャを変更することを考えています。各スレッドは、独自のアクティビティで動作します。(管理する一連のさまざまな活動があります)。

現在のインフラストラクチャの欠点は、スレッド (アクティビティ) 自体の数と同じ数の待機ハンドルがあり、スレッド数が増減し続けることができることです。

現在のロジックは次のとおりです。それぞれが独自の AutoResetEvent とアクティビティに関連付けられたスレッドのセット Thread1-Event1-activity1 Thread2-Event2-activity2

各スレッドはループを実行し、ループ内で操作を実行します。

以下のような擬似コード。

そのため、操作をスレッドのキューに入れるコントローラーはイベントを設定するだけで、スレッドはそのタスクを完了し、アクティビティ n の次の要求を待機するために戻ります。

使用される WaitHandles の数を減らすために私が考えているインフラストラクチャは、すべてのスレッドで 1 つのセマフォを使用することです。

セマフォ カウントを任意の最大数 100 に設定します。セマフォの初期カウントを 0 に設定します。

これで、セマフォは基本的にすべてのスレッドに対してロックされた状態になります。

すべてのスレッドが以前と同じようにループを実行するようになりました

ただし、アクティビティには固定スレッドはありません (アクティビティは、集中化された同時実行キューに入れられます)。アクティビティをキューに入れるコントローラーは、次の操作を実行します。

セマフォの実装は、複数の WaitHandle アプローチよりも優れていますか? もしそうなら、なぜですか？単一のセマフォ アプローチは競合の増加を意味すると私は感じています。

誰かがこれに光を当てることができれば。それは素晴らしいことだ。

更新: リクエストのキューイングが少し独特なので、BlockingCollection は使用していません。複数の種類のアクティビティ (タイプ 1 から n) があり、タイプ n の 1 つのアクティビティが実行されている場合、同じタイプ (たとえば n) の複数のアクティビティを実行できないという条件があります。そのため、最初はアクティビティ タイプごとに 1 つのスレッドを使用していました。関連する待機ハンドルを 1 に減らそうとしていたので、セマフォ アプローチが適合するかどうかを確認しようとしています。しかし、私の懸念は、セマフォ ルートに行くと、ロックの競合が増えることです。私のシナリオでは、常に 1 つまたは 2 つのスレッドがアクティブになっている可能性があります。つまり、残りのすべてのスレッドが、開いているセマフォ内の 1 つまたは 2 つの開いているスロットをめぐって競合します。