gpt4 book ai didi

multithreading - Delphi死锁解释/解决方案

转载 作者:行者123 更新时间:2023-12-03 15:02:12 29 4
gpt4 key购买 nike

在服务器应用程序上,我们有以下内容:一个称为 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 方法。这种情况容易陷入僵局吗?有人可以帮助我理解为什么这里会发生僵局吗?

我们知道,有时,当客户端执行特定操作时,导致系统锁定,那么我最终可以找到这一点,即同一类的临界区从不同的点到达两次( Scheduler 和 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 < lock_already_acquired.id 则抛出异常)

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

关于multithreading - Delphi死锁解释/解决方案,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/5958353/

29 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com