【问题标题】:How can .NET threads be waiting on a syncblk which is not owned by any thread?.NET 线程如何等待不属于任何线程的 syncblk?
【发布时间】:2011-12-11 03:32:21
【问题描述】:

我的应用程序有一个故障转储,显示一堆线程在等待同步块,而同步块显示它没有拥有线程。这怎么可能?我正在尝试在测试应用程序中重现该症状,但我无法弄清楚产生该结果可能会发生什么......让拥有的线程退出或在不释放 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

【问题讨论】:

    标签: c# .net multithreading windbg monitor


    【解决方案1】:

    SyncBlock 000000019f1ec5d8 是没有所有者的。也是唯一一个具有偶数MonitorHeld 计数的。由于 MonitorHeld 增加了with 1 for the owner and 2 for each waiter,我的猜测是这是一个在转储之前释放的资源,并且还没有授予新的所有者。不公平的资源在释放时向所有服务员发出信号,服务员急于获取它(这种不公平的行为避免了护航锁)。直到等待者被调度并运行,并且第一个等待者抢到资源,才会有所有者。

    另见A high waiter count on a free critical section may indicate a lock convoy

    如果您正在调试应用程序中的性能问题,您可以 在一个非常奇怪的状态下跑过一个临界区:很多 线程正在等待它,但没有人拥有它!

    ...

    这个状态意味着临界区的前任拥有者拥有 刚刚退出它并发出一个等待线程接受它的信号,但是 线程还没有机会运行

    【讨论】:

    • 是的。或者线程在 GC 上被阻塞。总是有可能进行故障转储。
    • 感谢 Remus....阅读了一些关于 lock convoys 的信息,它完全完美地描述了我所看到的内容。应用程序似乎挂起,并且 CPU 被固定在 100%,但是如果我转储它,所有线程似乎都在等待获取该锁......似乎根本没有执行,如果我执行 !runaway all CPU 负载均匀分布在所有线程中。非常感谢!
    【解决方案2】:

    可能性一:syncblk 被清空,16 个线程中的下一个线程一旦再次被调度就会抢占它。 可能性 2:您的内存已损坏。

    【讨论】:

      【解决方案3】:

      你描述的可能有几个原因:

      • 拥有的线程变得不稳定,出现一些令人讨厌的访问冲突
      • 所属线程因 OutOfMemoryExceptions 而变得不稳定
      • 系统的某些部分(如驱动程序...)导致了奇怪的情况
      • 某些使用本机代码的第三方库导致进程变得不稳定
      • 框架的某些重要部分(如 GC/内存管理/线程管理)在执行某些重要操作时变得不稳定和/或死亡

      以上任何一个都很难重现......

      有关 syncblk 的精彩总结,请参阅 http://blogs.msdn.com/b/tess/archive/2006/01/09/a-hang-scenario-locks-and-critical-sections.aspx

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 2010-12-07
        • 1970-01-01
        • 1970-01-01
        • 2015-07-13
        • 2019-09-18
        • 1970-01-01
        • 2017-12-16
        相关资源
        最近更新 更多