Как потоки .NET могут ожидать syncblk, который не принадлежит ни одному потоку?

Question

У меня есть аварийный дамп из моего приложения, показывающий кучу потоков, ожидающих на syncblk, и syncblk показывает, что у него нет собственного потока.Как это возможно?Я пытаюсь воспроизвести симптом в тестовом приложении, и я не могу понять, что может произойти, чтобы привести к такому результату ... выход из потока-владельца или его смерть без освобождения syncblk все еще отображается как владелец объекта, только threadid - "XXX" .... Я проверил, используя полностью управляемый изящный выход и завершение жесткого потока через pinvoke .... Я проверил множество различных комбинаций ожиданий без импульсов, несовпадающих входов и выходов ...Ничто не создает syncblk, который блокирует потоки и не показывает владельца ... У меня заканчиваются идеи

Вот вывод из моего аварийного дампа, который я пытаюсь воспроизвести: (Примечание, индекс # 1236)

0:000> !syncblk
Index         SyncBlock MonitorHeld Recursion Owning Thread Info          SyncBlock Owner
 784 0000000004f12eb0            3         1 000000000508a460  32a8  68   00000001a0a20510
 966 0000000004f06928            1         1 00000000052c5da0  2380 114   00000001df3080f8
1085 0000000004f23088            1         1 00000000052c8080  496c 120   00000001a0325238
1144 0000000005160d20            1         1 00000000050968b0   d74  56   00000000ff61b570
1151 0000000004f0c2c8            1         1 000000000508d8b0  3f64  77   000000017f66dc20
1236 0000000004f0b4f8           16         0 0000000000000000     none    000000019f1ec5d8
1261 0000000004f0ffe8            1         1 0000000008f18fc0  446c  94   000000013f8e70b0
1306 0000000004f0e918            1         1 00000000052c91f0  406c 123   000000011f5936f8
1318 0000000004f0e528            3         1 0000000008f1d580  24d8 106   000000015fc73f28
1329 0000000004f0cc58            1         1 0000000005095740  2fbc  53   000000011f36d320
1332 0000000004f15b38            1         1 0000000008f16710  3804  87   000000019f964728
1387 0000000004f22350            1         1 0000000008f18420  5180  92   00000001a008ab08
1515 0000000004f1d5d0            1         1 00000000052c4c30  2b5c 111   00000000ffd3c068
1594 0000000004f19bc0            1         1 000000000508ea20  188c  80   000000012012c538
1660 0000000004f13608            1         1 00000000050892f0  32fc  65   00000001df800940
1682 00000000051608a0            1         1 000000000508c740  1d58  74   00000001bfa03d20
1746 0000000004f14e88            1         1 0000000008f1c9e0   e88 104   000000015f6fcd10
1883 0000000004f19938            1         1 0000000005092e90  27c4  46   00000000ff76d2b0
1886 0000000004f1b760            1         1 0000000008f19b60  2dd4  96   000000019fc07030
2036 0000000004f1ae10            1         1 0000000008f1be40  4f58 102   00000001dfcb9da8
2042 0000000004f12e68            1         1 00000000052c8c20  2300 122   000000015f6aaa98
2049 0000000004f1cda0            1         1 00000000052c9d90  1948 126   00000001df6fd688
2153 0000000004f16d88            1         1 0000000005094ba0  3f04  51   00000000ff677eb8
2262 0000000004f13de8            3         1 00000000052ca360   6fc 127   000000011fd7a450
2358 00000000050fc390            1         1 0000000009221280  3ca0 130   0000000120055ca0
-----------------------------
Total           2553
CCW             3
RCW             2
ComClassFactory 0
Free            1212

Answer 1

SyncBlock 000000019f1ec5d8 - тот, у которого нет владельца.Также является единственным с четным счетом MonitorHeld.Поскольку MonitorHeld увеличивает с 1 для владельца и 2 для каждого официанта , я предполагаю, что это ресурс, который был освобожден непосредственно перед тем, как был сделан дамп, и еще не был назначен новый владелец.Недобросовестные ресурсы сигнализируют всем официантам при освобождении, и официанты спешат их заполучить (это несправедливое поведение позволяет избежать блокировок конвоев).Пока официанты не будут запланированы и запущены, а первый официант не захватит ресурс, владельца не будет.

См. Также Большое количество официантов на свободном критическом участке может указывать на конвой блокировки :

Если вы отлаживаете проблему с производительностью в своем приложении, вы можете наткнуться на критический раздел в очень странном состоянии: его ожидает множество потоков, но никто не владеет им!

...

Это состояние означает, что предыдущий владелец критического раздела только что вышел из него и подал сигнал ожидающему потоку, чтобы принять его, но этот поток еще не получил возможности для запускапока что

Answer 2

То, что вы описываете, может иметь несколько причин:

• Поток владельца стал нестабильным с некоторыми неприятными нарушениями доступа
• Поток владельца стал нестабильным с OutOfMemoryExceptions
• Некоторая частьсистема (как драйвер ...) вызвала странную ситуацию
• Некоторая сторонняя библиотека, использующая собственный код, вызвала нестабильность процесса
• Некоторая существенная часть инфраструктуры (например, GC /управление памятью / управление потоками) стало нестабильным и / или умерло во время выполнения какой-то важной операции

Любое из перечисленного довольно сложно воспроизвести ...

Для хорошегорезюме по syncblk см. http://blogs.msdn.com/b/tess/archive/2006/01/09/a-hang-scenario-locks-and-critical-sections.aspx

Answer 3

Возможность 1: Syncblk очищается, и следующий из 16 потоков захватит его, как только он снова запланирован.Возможность 2: у вас повреждена память.