問題タブ [readerwriterlockslim]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c# - IDisposableおよびReaderWriterLockSlim
クラスがありMyClass
ます。このクラスにはフィールドがあります:(public ReaderWriterLockSlim rw;
より簡単なサンプルコードの場合はpublic)。多くのスレッドは、など MyClass
を使用してデータを読み取ることができます。rw.EnterReadLock
IDisposable
また、私はインターフェース を実装しました:
ご覧のとおり、問題は、myClassオブジェクトでMyClass
2番目のスレッドが呼び出されたときに1つのスレッドが使用されている場合です。Dispose
ReaderWriterLockSlimを破棄すると、アプリケーションがクラッシュするため、破棄できません。では、管理対象リソースを解放する行を削除する必要がありますか?とにかく、ReaderWriterLockSlimは近い将来GCによって収集されますよね?(しかし、このクラスのリソースは高価ですか?)
たぶん、Dispose metodなどにlock(syncObject)を追加する必要がありますか?
編集:AllocHGlobalも扱っているので、すべてのスレッドがへの読み取り/書き込みを停止するまで待つ必要がありmyClass
ます。
別の視点:
visual-studio-2012 - C ++/CLIを使用したSystem::Threading名前空間にReaderWriterLockSlimがありません
最近VisualStudio2012をインストールし、アプリに必要な.netアセンブリにアクセスするために使用される小さなC ++/cliを使用した混合モードC++アプリケーションである既存のプロジェクトを再コンパイルしてみました。
C ++ / CLI実装の一部は、ReaderWriterLockSlimクラスを使用して、複数のスレッドから辞書へのアクセスを保護します。
これはすべてコンパイルされ、VS2010で正常に動作します。ただし、VS0212および.Net 4.5にアップグレードした後、System :: Threading名前空間でReaderWriterLockSlimが見つからないため、プロジェクトはコンパイルに失敗します。
新しいC#プロジェクトを作成し、ReaderWriterLockSlimを問題なく使用できるので、インストールは問題ないと確信しています。
以下に示す新しいC++プロジェクトも失敗します。ここまたはgoogleのいずれかで、C ++/CLIユーザーのために意図的に削除されているこのクラスへの参照を見つけることができません。他の誰かが同じような経験をしたことがありますか。
c# - c# ReaderWriterLockSlim は、ExitReadLock を呼び出す割り込みスレッドの後に破損しています
一連の法的措置の後、ReaderWriterLockSlim が壊れたように見えるシナリオに遭遇しました。
フローは次のとおりです。
- スレッド 1 はライター ロック 1 を取得します
- スレッド 2 がリーダー lock1 を取得しようとします - ブロック
- スレッド 2 が中断され、lock1.ExitReadLock を呼び出します。スレッド 2 はロックを取得しませんでした。例外がスローされるはずだったようです。
- スレッド 1 は、lock1 のライター ロックを終了します
- lock1.EnterReadLock を取得しようとするスレッドは、永久にブロックされます
上記のステージ 3 の後、デバッガーは lock1.CurrentReadCount が破損していることを示します - オーバーフローして 0x7FFFFFF になったようです。
誰かがこれに遭遇したのだろうか、それとも何かが足りないのかもしれません。
それを再現するコード:
c# - ReaderWriterLockSlim によるマルチスレッド更新
最初にゲームのデザインを始めたときに大きな間違いを犯したと思います。コードの一部またはすべてを提供することもできますが、複雑すぎます。だから我慢してください。
デザインのより高度な段階に到達した今、スレッドに関する大きな問題に直面しています。
更新中、3 つのタスクを同時に実行します。Update、HitTesting、AI はさらに多くのスレッドに分割されています。
- 更新では、すべてのオブジェクトの動き (物理を含む) とアニメーションを実行する必要があります。
- HitTesting は、何千ものオブジェクト間ですべてのヒット テストを実行しますが、まだ多くの最適化が必要です…. 分断と征服のようなものは正しくなります。
- AI は、更新サイクルによって実行されるオブジェクトにコマンドを発行します。左折、右折、火事など。
そしてもちろん、私たちは持っています
- draw… または私の場合は、描画中に GetSprites を実行します。これは、更新プロセス以外のすべてよりも完全に優先する必要があります。
- そして、まだ実装されていないサウンドとメッセージ システム。
お分かりのように、これはマルチタスキングにとって最適なプロセスではありません。それらはすべて同じオブジェクトで機能するためですが、そうする必要があります。
だから… System.Threading.ReaderWriterLockSlim を実装することを考えました
そして、これが私の本当の質問です。どうすればそれを行うことができますか?
- Update が私の描画データへの唯一のライターであるためです。
- Drawing は純粋な Reader です
- HitTesting は、boundingRectangle と Matrix を再計算する必要があるかもしれませんが、描画には影響しません
- AI は位置データを読み取ってコマンドを発行するだけで済み、次のサイクルで Update によって読み取られ、個別のクラスのグループに分けられます (マスター/パペットと呼んでいますが、おそらく正式な/より適切な名前が付けられています)。
スレッドが必要とするさまざまなプロパティをロックするために、さまざまな ReaderWriterLockSlim オブジェクトを実装することは理にかなっていますか?
更新中にロックされたオブジェクトをバイパスして (AI または HitTesting のいずれかによって) 制御し、次のオブジェクトを取得して、後でロックが解除されたときにそれを実行できるようにしたい (または、更新に時間がかかりすぎる場合はスキップすることもできますが、実行します)次のサイクルで)
高度なスレッド化に関する本やサイトを知っている人はいますか? どこにでもある通常の小さな例ではないので、これを理解できますか?
1 週間以上立ち往生しているので、先に進みたいと思います。
どんな助けでも感謝します。
これは、オブジェクト間の衝突検出に使用するコードです。ずいぶん前に見つけた C++ の例から変換しましたが、場所を思い出せません。
iSpriteInfo は次のように定義されています
multithreading - ReaderWriter ロック、私のコードは例外を与えるだけです
私は Reader Writer Problem を実装しようとしています..何が問題なのかわかりませんか?
誰でも理由を理解するのを手伝ってもらえますか?
................................................................... .
それは私にますます多くの例外を与えるだけです!!! 待機中のスレッドがないときに notify() を呼び出した場合、問題はありますか?
定数文字列またはグローバル オブジェクトで wait() を呼び出すことはできないと思います。私はここでこれを見ました!
.net - ReaderWriterLockSlim は永久にロックされます
良い時間です。
私の問題は次のとおりです。
多数のスレッドがイベントが読み取りロックを取得するのを待っており、1 つのスレッドがイベントが書き込みロックを取得するのを待っています。その時点では、どのスレッドもロックを保持していません。
ReaderWriterLockSlim.cs から:
最初に、この種の破損をロックの状態にするスレッドの中止を想定しました。問題を簡単に再現できます: http://chabster.blogspot.com/2013/07/a-story-of-orphaned-readerwriterlockslim.html。
ロックの使用法を次のようにしました
そして、中断は try { /* リソース使用コード */ } 内でのみ発生する可能性があると確信していました。
今、同じ問題で別のダンプを取得し、アイデアがなくなりました。
これは、24 コア環境で時々発生すると言わざるを得ません。ht/milticore/multiprocessor システムの RWLS バグでしょうか? ReaderWriterLockSlim クラスは、マルチコア環境で潜在的な問題になる可能性があるインターロック命令なしでメンバーを更新することがわかりました。
PS: ReaderWriterLockSlim の作者である Joe Duffy から連絡を取りたいのですが、メールで連絡が取れませんでした。