良い時間です。
私の問題は次のとおりです。
多数のスレッドがイベントが読み取りロックを取得するのを待っており、1 つのスレッドがイベントが書き込みロックを取得するのを待っています。その時点では、どのスレッドもロックを保持していません。
0:173> !do 0x0000000001c679f8
Name: System.Threading.ReaderWriterLockSlim
...
Value Name
1 fIsReentrant
0 myLock
1 numWriteWaiters
28 numReadWaiters
0 numWriteUpgradeWaiters
0 numUpgradeWaiters
0 fNoWaiters
-1 upgradeLockOwnerId
-1 writeLockOwnerId
000000000381eb38 writeEvent
00000000035a32e0 readEvent
0000000000000000 upgradeEvent
0000000000000000 waitUpgradeEvent
9 lockID
0 fUpgradeThreadHoldingRead
1073741824 owners
0 fDisposed
0:173> .formats 0n1073741824
Evaluate expression:
Hex: 00000000`40000000
ReaderWriterLockSlim.cs から:
private const uint WAITING_WRITERS = 0x40000000;
最初に、この種の破損をロックの状態にするスレッドの中止を想定しました。問題を簡単に再現できます: http://chabster.blogspot.com/2013/07/a-story-of-orphaned-readerwriterlockslim.html。
ロックの使用法を次のようにしました
try {} finally { lock.EnterXYZ(); }
try { /* resource usage code */ } finally { lock.ExitXYZ(); }
そして、中断は try { /* リソース使用コード */ } 内でのみ発生する可能性があると確信していました。
今、同じ問題で別のダンプを取得し、アイデアがなくなりました。
これは、24 コア環境で時々発生すると言わざるを得ません。ht/milticore/multiprocessor システムの RWLS バグでしょうか? ReaderWriterLockSlim クラスは、マルチコア環境で潜在的な問題になる可能性があるインターロック命令なしでメンバーを更新することがわかりました。
PS: ReaderWriterLockSlim の作者である Joe Duffy から連絡を取りたいのですが、メールで連絡が取れませんでした。