为什么我的多线程应用程序有时会在关闭时挂起？

Question

我在我的应用程序中使用了几个关键部分。临界区可防止不同线程同时修改和访问大型数据块。

据我所知，除了有时应用程序在退出时挂起之外，一切都正常工作。我想知道这是否与我使用关键部分有关。

是否有在析构函数中释放 TCriticalSection 对象的正确方法？

感谢您的所有回答。我正在再次查看我的代码并牢记这些新信息。干杯!

Answer 1

正如 Rob 所说，唯一的要求是确保关键部分当前不属于任何线程。甚至连即将摧毁它的线程也没有。因此，正确销毁 TCriticalSection 没有可遵循的模式。仅您的应用程序必须采取措施以确保发生所需的行为。

如果您的应用程序被锁定，那么我怀疑是否释放了任何负责的关键部分。正如 MSDN 所说（在 Rob 发布的链接中），DeleteCriticalSection()（这最终是释放 TCriticalSection 所调用的）不会阻塞任何线程。

如果您释放其他线程仍在尝试访问的关键部分，您将遇到访问冲突和其他意外行为，而不是死锁，因为这个小代码示例应该可以帮助您演示：

implementation

uses
  syncobjs;


  type
    tworker = class(tthread)
    protected
      procedure Execute; override;
    end;


  var
    cs: TCriticalSection;
    worker: Tworker;


procedure TForm2.FormCreate(Sender: TObject);
begin
  cs := TCriticalSection.Create;

  worker := tworker.Create(true);
  worker.FreeOnTerminate := TRUE;
  worker.Start;

  sleep(5000);

  cs.Enter;

  showmessage('will AV before you see this');
end;

{ tworker }

procedure tworker.Execute;
begin
  inherited;
  cs.Free;
end;

添加到表单的实现单元，更正根据需要，FormCreate() 事件处理程序的“TForm2”引用。

在 FormCreate() 中，这会创建一个关键部分，然后启动一个线程，其唯一目的是释放该部分。我们引入一个 Sleep() 延迟来给线程时间来初始化和执行，然后我们尝试自己进入临界区。

我们当然不能，因为它已经被释放了。但是我们的代码并没有挂起 - 它在尝试访问其他资源所拥有的资源时并没有死锁，它只是崩溃了，因为我们正在尝试访问不再存在的资源。

在这种情况下，通过在关键部分引用被释放时对它进行 NIL 操作，您可以更加确定地创建 AV。

现在，尝试将 FormCreate() 代码更改为：

  cs := TCriticalSection.Create;

  worker := tworker.Create(true);
  worker.FreeOnTerminate := TRUE;

  cs.Enter;
  worker.Start;

  sleep(5000);

  cs.Leave;

  showmessage('appearances can be deceptive');

这会改变一些事情...现在主线程将获得关键部分的所有权 - 工作线程现在将释放关键部分，同时它仍由主线程拥有。

但在这种情况下，对 cs.Leave 的调用不一定会导致访问冲突。在这种情况下（afaict）发生的所有事情是允许拥有线程按照预期“离开”该部分（当然不是，因为该部分已经消失，但似乎 到它已离开之前进入的部分的线程） ...

...在更复杂的情况下，可能会出现访问冲突或其他错误，因为之前用于关键部分对象的内存可能会重新分配给当你调用它的 Leave() 方法时，它会调用一些其他对象，从而导致调用一些其他未知对象或访问无效内存等。

再次，更改worker.Execute()，使其成为释放后的关键部分引用'它将确保尝试调用 cs.Leave() 时发生访问冲突，因为 Leave() 调用 Release() 且 Release() 是虚拟的 - 调用带有 NIL 引用的虚拟方法可以保证 AV（Enter( 同上） ），它调用虚拟 Acquire() 方法）。

无论如何：

最坏的情况：异常或奇怪的行为

“最好”的情况：所属线程似乎认为它已正常“离开”该部分。

在这两种情况下，死锁或挂起都不会仅仅因为一个线程中的关键部分被释放而其他线程尝试进入或离开该关键部分而发生。

所有这些都是一种迂回的说法，听起来你的线程代码中有一个更基本的竞争条件，与关键部分的释放没有直接关系。

无论如何，我希望我的一点点调查工作能让你走上正确的道路。

Answer 2

只要确保没有任何东西仍然拥有该临界区即可。否则，MSDN 解释，“等待所有权的线程的状态删除的关键部分是未定义的。”除此之外，像对待所有其他对象一样，对其调用 Free 。

Answer 3

据我所知，除了有时应用程序在退出时挂起之外，一切都正常工作。我想知道这是否与我使用关键部分有关。

是的。但问题可能不在于破坏。你可能遇到了僵局。

死锁是指两个线程等待两个独占资源，每个线程都想要这两个资源，但每个线程只拥有一个资源：

//Thread1:
FooLock.Enter;
BarLock.Enter;

//Thread2:
BarLock.Enter;
FooLock.Enter;

解决这些问题的方法是对锁进行排序。如果某个线程想要其中两个，则必须仅按特定顺序输入它们：

//Thread1:
FooLock.Enter;
BarLock.Enter;

//Thread2:
FooLock.Enter;
BarLock.Enter;

这样就不会发生死锁。

很多事情都会引发死锁，不仅仅是两个关键部分。例如，您可能使用过 SendMessage（同步消息调度）或 Delphi 的 Synchronize AND 一个关键部分：

//Thread1:
OnPaint:
  FooLock.Enter;
  FooLock.Leave;

//Thread2:
FooLock.Enter;
Synchronize(SomeProc);
FooLock.Leave;

Synchronize 和 SendMessage 将消息发送到 Thread1。为了分派这些消息，Thread1 需要完成它正在做的任何工作。例如，OnPaint 处理程序。

但要完成绘画，它需要 FooLock，该 FooLock 由等待 Thread1 完成绘画的 Thread2 获取。僵局。

解决这个问题的方法是要么永远不要使用 Synchronize 和 SendMessage（最好的方法），或者至少在任何锁之外使用它们。

是否有在析构函数中释放 TCriticalSection 对象的正确方法？

在析构函数中或不在析构函数中释放 TCriticalSection 的位置并不重要。

但在释放 TCriticalSection 之前，您必须确保所有可能使用它的线程都已停止或处于无法再尝试进入此部分的状态。

例如，如果您的线程在分派网络消息时进入此部分，则必须确保网络已断开连接并且所有待处理消息均已处理。

如果不这样做，在大多数情况下会触发访问冲突，有时什么也不会发生（如果你幸运的话），并且很少会引发死锁。

Answer 4

使用 TCriticalSection 以及临界区本身并没有什么神奇之处。尝试用普通的 API 调用替换 TCriticalSection 对象：

uses
  Windows, ...

var
  CS: TRTLCriticalSection;

...

EnterCriticalSection(CS);
....
here goes your code that you have to protect from access by multiple threads simultaneously
...
LeaveCriticalSection(FCS);
...

initialization
  InitializeCriticalSection(CS);

finalization
  DeleteCriticalSection(CS);

切换到 API 不会损害代码的清晰度，但也许有助于揭示隐藏的错误。

Answer 5

您需要使用 try..finally 块来保护所有关键部分。

使用 TRTLLCriticalSection 而不是 TCriticalSection 类。它是跨平台的，TCriticalSection 只是它的一个不必要的包装。

如果数据处理过程中出现任何异常，那么临界区就没有留下，另一个线程可能会阻塞。

如果您想要快速响应，您还可以将 TryEnterCriticalSection 用于某些用户界面过程等。

以下是一些好的实践规则：

1. 将 TRTLLCriticalSection 设为类的属性；
2. 在类构造函数中调用InitializeCriticalSection，然后在类析构函数中调用DeleteCriticalSection；
3. 使用 EnterCriticalSection()...尝试...做一些事情...最后 LeaveCriticalSection();结尾;

这是一些代码示例：

type
  TDataClass = class
  protected
    fLock: TRTLCriticalSection;
  public
    constructor Create;
    destructor Destroy; override;
    procedure SomeDataProcess;
  end;

constructor TDataClass.Create;
begin
  inherited;
  InitializeCriticalSection(fLock);
end;

destructor TDataClass.Destroy;
begin
  DeleteCriticalSection(fLock);
  inherited;
end;

procedure TDataClass.SomeDataProcess;
begin
  EnterCriticalSection(fLock);
  try
    // some data process
  finally
    LeaveCriticalSection(fLock);
  end;
end;

Answer 6

如果应用程序中唯一的显式同步代码是通过关键部分，那么追踪它应该不会太困难。

您表明您只看到终止时的僵局。当然，这并不意味着它不会在您的应用程序正常运行期间发生，但我的猜测（我们必须在没有更多信息的情况下猜测）是这是一个重要的线索。

我假设该错误可能与强制终止线程的方式有关。如果一个线程在仍持有锁的情况下终止，但另一个线程在有机会终止之前尝试获取锁，则会发生您所描述的死锁。

可以立即解决问题的一个非常简单的方法是确保正如其他人正确所说的那样，锁的所有使用都受到 Try/Finally 的保护。这确实是一个关键点。

Delphi 中的资源生命周期管理有两种主要模式，如下所示：

lock.Acquire;
Try
  DoSomething();
Finally
  lock.Release;
End;

另一种主要模式是在 Create/Destroy 中配对获取/释放，但这在锁的情况下不太常见。

假设您对锁的使用模式正如我所怀疑的那样（即在同一方法内获取和释放），您能否确认所有使用都受到 Try/Finally 的保护？

Answer 7

如果您的应用程序仅在退出时挂起/死锁，请检查所有线程的终止事件。如果主线程发出信号通知其他线程终止，然后在释放它们之前等待它们。重要的是不要在终止事件中进行任何同步调用。当主线程等待工作线程终止时，这可能会导致死锁。但同步调用正在主线程上等待。

Answer 8

不要在对象的析构函数中删除关键部分。有时会导致您的应用程序崩溃。

使用单独的方法删除关键部分。

过程 someobject.deleteCritical();
开始
删除关键部分（关键部分）；
结尾;

析构函数 someobject.destroy();
开始
// 在这里执行您的发布任务
结尾;

1）你调用删除临界区
2）释放（free）对象后