如何才能.NET线程正在等待它不被任何线程拥有一个syncblk？ [英] How can .NET threads be waiting on a syncblk which is not owned by any thread?
问题描述
我有我的应用程序显示了一堆等待一个syncblk线程的崩溃转储和syncblk表明，它没有所属线程。这怎么可能？我试图重现症状在测试应用程序，我想不出什么可能发生在产生结果....具有拥有线程退出或死亡而不释放syncblk仍显示为持有对象，只是主题ID为XXX......我通过的PInvoke采用完全托管的正常退出和硬线程终止测试....我测试了一堆等待的不同组合，无脉冲，不匹配的进入和退出...没有产生syncblk以阻止线程，没有显示出主人.....我跑出来的想法
下面是我的故障转储，我正在尝试复制输出（注：指数＃1236）
0：000＆GT; ！syncblk
指数的SyncBlock MonitorHeld递归拥有主题信息的SyncBlock业主
784 0000000004f12eb0 3 1 000000000508a460 32a8 68 00000001a0a20510
966 0000000004f06928 1 00000000052c5da0 2380 114 00000001df3080f8
1085 0000000004f23088 1 00000000052c8080 496c 120 00000001a0325238
1144 0000000005160d20 1 00000000050968b0 D74 56 00000000ff61b570
1151 0000000004f0c2c8 1 000000000508d8b0 3f64 77 000000017f66dc20
1236 0000000004f0b4f8 16 0 0000000000000000无000000019f1ec5d8
1261 0000000004f0ffe8 1 0000000008f18fc0 446c 94 000000013f8e70b0
1306 0000000004f0e918 1 00000000052c91f0 406C 123 000000011f5936f8
1318 0000000004f0e528 3 1 0000000008f1d580 24d8 106 000000015fc73f28
1329 0000000004f0cc58 1 0000000005095740 2fbc 53 000000011f36d320
1332 0000000004f15b38 1 0000000008f16710 3804 87 000000019f964728
1387 0000000004f22350 1 0000000008f18420 5180 92 00000001a008ab08
1515 0000000004f1d5d0 1 00000000052c4c30 2b5c 111 00000000ffd3c068
1594 0000000004f19bc0 1 000000000508ea20 188 80 000000012012c538
1660 0000000004f13608 1 00000000050892f0 32fc 65 00000001df800940
1682 00000000051608a0 1 000000000508c740 1d58 74 00000001bfa03d20
1746 0000000004f14e88 1 0000000008f1c9e0 E88 104 000000015f6fcd10
1883年0000000004f19938 1 0000000005092e90 27c4 46 00000000ff76d2b0
1886年0000000004f1b760 1 0000000008f19b60 2dd4 96 000000019fc07030
2036 0000000004f1ae10 1 0000000008f1be40 4f58 102 00000001dfcb9da8
2042 0000000004f12e68 1 00000000052c8c20 2300 122 000000015f6aaa98
2049 0000000004f1cda0 1 00000000052c9d90 1948年126 00000001df6fd688
2153 0000000004f16d88 1 0000000005094ba0 3f04 51 00000000ff677eb8
2262 0000000004f13de8 3 1 00000000052ca360 6FC 127 000000011fd7a450
2358 00000000050fc390 1 0000000009221280 3ca0 130 0000000120055ca0
-----------------------------
共有2553
CCW 3
RCW 2
ComClassFactory 0
免费1212
的SyncBlock 000000019f1ec5d8是一个没有所有者。也是国内唯一一家具有偶数 MonitorHeld 计数。由于MonitorHeld增量<一href="http://blogs.msdn.com/b/tess/archive/2006/01/09/a-hang-scenario-locks-and-critical-sections.aspx">with 1所有者和2对每个服务员我的猜测是，这是转储拍摄之前，还有尚未获批新主人已发布的资源。不公平的资源的信号释放所有的服务员和服务员急于得到它（这个不公平的行为，避免车队锁）。直到服务员安排和运行，以及第一服务员抓住了资源，就没有主人。
如果你正在调试应用程序中的性能问题，则可能 跨临界区中一个很奇怪的状态下运行：很多 线程都在等待，但没人真正拥有它！
...
这状态意味着临界区的previous所有者 刚刚离开它，并暗示等待线程把它，但 线程尚未得到运行还有一个机会
I have a crash dump from my app showing a bunch of threads waiting on a syncblk, and the syncblk shows that it has no owning thread. How is that possible? I'm trying to reproduce the symptom in a test app, and I can't figure out what could possibly happen to produce that result....having the owning thread exit or die without releasing the syncblk still shows up as owning the object, just the threadid is "XXX"....I've tested using fully managed graceful exit and hard thread termination via pinvoke....I tested a bunch of different combinations of waits without pulses, mismatched enters and exits...nothing produces a syncblk which blocks threads and shows no owner.....I'm running out of ideas
Here is the output from my crashdump that I'm trying to replicate: (Note index #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
SyncBlock 000000019f1ec5d8 is the one with no owner. Is also the only one with an even MonitorHeld count. Since the MonitorHeld increments with 1 for the owner and 2 for each waiter my guess would be that this is a resource that was released just before the dump was taken, and there was not yet granted a new owner. Unfair resources signal all waiters on release and the waiters rush to acquire it (this unfair behavior avoid convoy locks). Until the waiters are scheduled and run, and the first waiter grabs the resource, there will be no owner.
See also A high waiter count on a free critical section may indicate a lock convoy:
If you're debugging a performance problem in your application, you may run across a critical section in a very strange state: A lot of threads are waiting for it, but nobody owns it!
...
This state means that the previous owner of the critical section has just exited it and signalled a waiting thread to take it, but that thread hasn't yet gotten a chance to run yet
这篇关于如何才能.NET线程正在等待它不被任何线程拥有一个syncblk？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
