multithreading - 退出时应用程序在 SysUtils -> DoneMonitorSupport 中挂起

Question

我正在编写一个线程密集型应用程序，它在退出时挂起。

我已经追踪到系统单元，找到了程序进入无限循环的地方。它在 SysUtils 第 19868 行 -> DoneMonitorSupport -> CleanEventList :

repeat until InterlockedCompareExchange(EventCache[I].Lock, 1, 0) = 0;

我在网上搜索了一个解决方案，发现了几个 QC 报告:

http://qc.embarcadero.com/wc/qcmain.aspx?d=95194

http://qc.embarcadero.com/wc/qcmain.aspx?d=90487

不幸的是，这些似乎与我的情况无关，因为我不使用 TThreadList 或 TMonitor .

我很确定我的所有线程都已完成并已被销毁，因为所有线程都继承自保持创建/销毁计数的基本线程。

有没有人遇到过类似的行为？您是否知道任何发现根本原因可能存在的策略？

Answer 1

我一直在看TMonitor实现了锁，终于有了一个有趣的发现。为了有点戏剧性，我将首先告诉你锁是如何工作的。
当您拨打任何电话时 TMonitor TObject 上的函数, TMonitor 的新实例创建记录并将该实例分配给 MonitorFld在对象本身内部。这个赋值是以线程安全的方式进行的，使用 InterlockedCompareExchangePointer .因为这个伎俩TObject仅包含一个指针大小的数据量以支持 TMonitor ，它不包含完整的 TMonitor 结构。这是一件好事。
此 TMonitor结构包含许多记录。我们将从 FLockCount: Integer 开始 field 。当第一个线程使用 TMonitor.Enter()在任何对象上，这个组合的锁计数器字段的值为零。再次使用 InterlockedCompareExchange获取锁并启动计数器的方法。调用线程将没有锁定，没有上下文切换，因为这一切都是在进程中完成的。
当第二个线程尝试 TMonitor.Enter()同一个对象，它的第一次锁定尝试将失败。当这种情况发生时，Delphi 遵循两种策略:

如果开发者使用 TMonitor.SetSpinCount()设置“旋转”的次数，然后 Delphi 将执行忙等待循环，旋转给定的次数。这对于小锁来说非常好，因为它允许在不进行上下文切换的情况下获取锁。

如果自旋计数到期(或者没有自旋计数，并且默认自旋计数为零)，TMonitor.Enter()将对 TMonitor.GetEvent() 返回的事件发起等待.换句话说，它不会忙等待浪费 CPU 周期。记住 TMonitor.GetEvent()因为这非常重要。

假设我们有一个获取锁的线程和一个尝试获取锁但现在正在等待 TMonitor.GetEvent 返回的事件的线程。 .当第一个线程调用 TMonitor.Exit()它会注意到(通过 FLockCount 字段)至少有一个其他线程阻塞。所以它立即脉冲通常应该是先前分配的事件(调用 TMonitor.GetEvent() )。但是由于两个线程，调用 TMonitor.Exit() 的那个线程还有那个叫 TMonitor.Enter()实际上可能会拨打 TMonitor.GetEvent()同时，里面还有一些小技巧 TMonitor.GetEvent()确保只分配一个事件，与操作顺序无关。
对于一些更有趣的时刻，我们现在将深入研究 TMonitor.GetEvent() 的方式作品。这东西住在 System里面单元(你知道，我们不能重新编译来玩)，但事实证明它通过 System.MonitorSupport 将实际分配事件的职责委托(delegate)给另一个单元。指针。这指向了 TMonitorSupport 类型的记录声明了 5 个函数指针:

NewSyncObject - 为同步目的分配一个新事件

FreeSyncObject - 释放为同步目的分配的事件

NewWaitObject - 为等待操作分配一个新事件

FreeWaitObject - 解除等待事件

WaitAndOrSignalObject - 嗯.. 等待或信号。

事实证明， NewXYZ 返回的对象函数可以是任何东西，因为它们只用于调用 WaitXYZ以及对 FreeXyzObject 的相应调用.这些函数在 SysUtils 中的实现方式旨在为这些锁提供最少量的锁定和上下文切换；因为对象本身(由 NewSyncObject 和 NewWaitObject 返回)不是直接由 CreateEvent() 返回的事件, 但指向 SyncEventCacheArray 中的记录的指针.更进一步，直到需要时才会创建实际的 Windows 事件。因此， SyncEventCacheArray 中的记录包含几个记录:

TSyncEventItem.Lock - 这告诉 Delphi 是否现在正在将 Lock 用于任何事情和

TSyncEventItem.Event - 如果需要等待，这将保存将用于同步的实际事件。

当应用程序终止时， SysUtils.DoneMonitorSupport遍历 SyncEventCacheArray 中的所有记录并等待锁变为零，即等待锁停止被任何东西使用。从理论上讲，只要该锁不为零，则至少有一个线程可能正在使用该锁 - 因此明智的做法是等待，以免导致 AccessViolations 错误。我们终于解决了当前的问题:HANGING in SysUtils.DoneMonitorSupport为什么应用程序可能会在 SysUtils.DoneMonitorSupport 中挂起，即使它的所有线程都正确终止了？
因为使用 NewSyncObject 中的任何一个分配了至少一个 Event或 NewWaitObject没有使用它对应的 FreeSyncObject 被释放或 FreeWaitObject .我们回到 TMonitor.GetEvent()常规。它分配的事件保存在 TMonitor与用于 TMonitor.Enter() 的对象相对应的记录.指向该记录的指针仅保存在该对象的实例数据中，并在应用程序的整个生命周期内保存在那里。搜索字段名称， FLockEvent ，我们在 System.pas 中找到了这个文件:

procedure TMonitor.Destroy;
begin
  if (MonitorSupport <> nil) and (FLockEvent <> nil) then
    MonitorSupport.FreeSyncObject(FLockEvent);
  Dispose(@Self);
end;

并在此处调用该记录析构函数: procedure TObject.CleanupInstance .
换句话说，只有当用于同步的对象被释放时，最终的同步事件才会被释放!
回答 OP 的问题:
应用程序挂起，因为至少有一个用于 TMonitor.Enter() 的 OBJECT没有被释放。
可能的解决方案:
不幸的是我不喜欢这个。这是不对的，我的意思是不释放一个小对象的惩罚应该是一个小的内存泄漏，而不是一个挂起的应用程序!这对于服务应用程序尤其不利，因为服务可能会永远挂起，不会完全关闭但无法响应任何请求。
Delphi 团队的解决方案？他们不应该卡在 SysUtils 的终结代码中。单位，无论如何。他们可能应该忽略 Lock并移至关闭事件句柄。在那个阶段(SysUtils 单元的最终确定)，如果仍然有代码在某个线程中运行，那么它的状态非常糟糕，因为大多数单元已经完成，它没有在其设计运行的环境中运行。
对于delphi用户？我们可以更换 MonitorSupport使用我们自己的版本，在最终确定时不进行那些广泛测试的版本。