死锁Delphi解释/解决方案

Question

在服务器应用程序中,我们有以下内容:一个名为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 Thread的上下文中运行.

Scheduler有自己的线程运行,它直接调用JobManager方法.这种情况容易出现死锁吗？有人能帮助我理解为什么会发生僵局吗？

我们知道,有时候,当客户端执行特定操作,导致系统锁定时,我终于可以找到这一点,同一类的关键部分从不同点(调度程序和JobManager的消息处理程序方法).

更多信息

我想补充一点(这可能是愚蠢的,但无论如何......)在DoSomething里面还有另外一个

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

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

Answer 1

关于您的系统没有足够的信息能够明确地告诉您 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 < lock_already_acquired.id 则抛出异常）

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