Delphi死锁解释/解决方案

在服务器应用程序上，我们有以下内容： 一个称为 JobManager 的单例类。 另一个类是 Scheduler，它不断检查是否需要向 JobManager 添加任何类型的作业。

当需要这样做时，调度程序会执行以下操作：

TJobManager.Singleton.NewJobItem(parameterlist goes here...);

同时，在客户端应用程序上，用户执行一些操作来生成对服务器的调用。在内部，服务器向自身发送一条消息，监听该消息的类之一是 JobManager。 JobManager 处理该消息，并知道是时候将新作业添加到列表中，调用它自己的方法：

NewJobItem(parameter list...);

在 NewJobItem 方法中，我有这样的内容：

  CS.Acquire;
  try
    DoSomething;
    CallAMethodWithAnotherCriticalSessionInternally;
  finally
    CS.Release;
  end;

恰好系统此时陷入死锁（CS.Acquire）。 客户端和服务器应用程序之间的通信是通过 Indy 10 进行的。 我认为，触发向 JobManager 发送消息的服务器应用程序方法的 RPC 调用正在 Indy 线程的上下文中运行。

Scheduler有自己的线程在运行，它直接调用JobManager方法。这种情况容易陷入僵局吗？ 有人可以帮助我理解为什么这里会发生僵局吗？

我们知道，有时，当客户端执行特定操作时，导致系统锁定，那么我最终可以找到这一点，即从不同的点（调度程序和JobManager 的消息处理程序方法）。

更多信息

我想补充一点（这可能很愚蠢，但无论如何......）在 DoSomething 中还有另一个

  CS.Acquire;
  try
    Do other stuff...
  finally
    CS.Release; 
  end;

这个内部 CS.Release 对外部 CS.Acquire 做了什么？如果是这样，这可能是调度程序进入关键部分的点，并且所有锁定和解锁都会变得一团糟。

关于您的系统没有足够的信息能够明确地告诉您 JobManager 和 Scheduler 是否导致死锁，但如果它们都调用相同的 NewJobItem 方法，那么这不应该是问题，因为它们都会获取以相同的顺序锁定。

对于您的问题，您的 NewJobItem CS.acquire 和 DoSomething CS.acquire 是否相互交互：这取决于。如果两个方法中使用的锁对象不同，则这两个调用不应该是独立的。如果是同一个对象，则取决于锁的类型。如果您的锁是可重入锁（例如，它们允许从同一线程多次调用 acquire 并计算它们已被获取和释放的次数），那么这应该不是问题。另一方面，如果您有不支持重入的简单锁定对象，则 DoSomething CS.release 可以释放该线程的锁定，然后 CallAMethodWithAnotherCriticalSessionInternally 将在没有获得的 CS 锁定保护的情况下运行新作业项目。

当有两个或多个线程正在运行并且每个线程都在等待另一个线程完成其当前作业才能继续其自身时，就会发生死锁。

例如：

Thread 1 executes:

lock_a.acquire()
lock_b.acquire()
lock_b.release()
lock_a.release()


Thread 2 executes:

lock_b.acquire()
lock_a.acquire()
lock_a.release()
lock_b.release()

请注意，线程 2 中的锁以与线程 1 相反的顺序获取。现在，如果线程 1 获取了 lock_a，然后被中断，线程 2 现在运行并获取 lock_b，然后开始等待 lock_a 可用，然后才能继续。然后线程 1 继续运行，它所做的下一件事是尝试获取 lock_b，但它已经被线程 2 占用，因此它等待。最后，我们处于这样一种情况：线程 1 正在等待线程 2 释放 lock_b，线程 2 正在等待线程 1 释放 lock_a。

这是一个僵局。

常见的解决方案有以下几种：

1. 在所有代码中仅使用一个共享全局锁。这样就不可能有两个线程等待两个锁。这使得您的代码需要等待很长时间才能获得锁。
2. 只允许您的代码一次持有一把锁。这通常很难控制，因为您可能不知道或控制方法调用的行为。
3. 只允许您的代码同时获取多个锁，并同时释放它们，并且在已经获取锁的情况下禁止获取新锁。
4. 确保以相同的全局顺序获取所有锁。这是一种更常见的技术。

对于解决方案 4，您需要仔细编程并始终确保以相同的顺序获取锁/临界区。为了帮助调试，您可以对系统中的所有锁放置一个全局顺序（例如，每个锁只有一个唯一的整数），然后如果您尝试获取一个等级低于该锁的等级的锁，则抛出错误当前线程已经获取（例如，如果 new_lock.id

如果您无法放入全局调试辅助工具来帮助查找哪些锁已被无序获取，那么我建议您找到代码中获取任何锁的所有位置，然后打印一条调试消息：当前时间、调用acquire/release的方法、线程id以及正在获取的锁id。对所有发布调用也执行相同的操作。然后运行您的系统，直到出现死锁，并在日志文件中查找哪些线程已按什么顺序获取了哪些锁。然后确定哪个线程以错误的顺序访问其锁并更改它。