单线程且无递归的 C# 中的奇怪死锁

发布于 2024-11-03 20:45:51 字数 789 浏览 4 评论 0原文

我的 C# 应用程序遇到了奇怪的行为。

我通过 VS2010 在调试模式下运行应用程序,几个小时后,应用程序只是等待锁释放,但唯一存活的线程是等待锁释放的线程,并且该函数中没有递归:

class ProductionNode        {  
   private readonly object _lock = new object();  
   public bool Activate( long jobId )  
   {  
       lock(_lock) // Doesn't go through here  
       {  
         return DAL.InsertJobIfNotExists(jobId)>0; //SQL PLAIN INSERT IF NOT EXIST COMMAND  
       }  
  }
  public void HasJobs()  
  {  
       lock(_lock)
       {
           return DAL.HasProductionJobs();
       }  
  }
 }    

再次,当我使用 VS2010 暂停应用程序时,使用 ProductionNode 的唯一线程是等待 _lock 对象被释放的线程。

为了清楚起见,应用程序可能会在多个线程中激活生产节点,但在发生死锁的给定场景中,VS 仅显示使用 ProductionNode 对象的单个线程,其他线程使用其他对象类型。< /strong>

有什么想法吗?

干杯, 多伦

I am running into a strange behavior of my C# application.

I am running the application in debug mode via VS2010 and after several hours the application just waits for a lock release but the only thread which is alive is the one that waits upon the lock to be released and there is not recursion in that function:

class ProductionNode        {  
   private readonly object _lock = new object();  
   public bool Activate( long jobId )  
   {  
       lock(_lock) // Doesn't go through here  
       {  
         return DAL.InsertJobIfNotExists(jobId)>0; //SQL PLAIN INSERT IF NOT EXIST COMMAND  
       }  
  }
  public void HasJobs()  
  {  
       lock(_lock)
       {
           return DAL.HasProductionJobs();
       }  
  }
 }    

Again, when I am pausing the application using the VS2010 the only thread that uses the ProductionNode is the one that waits for the _lock object to be released.

To make things clear, the application might activate the production node in several threads but the in the given scenario where the deadlock occur the VS only displays a single thread which uses the ProductionNode object, the other threads uses other object types.

Any ideas?

Cheers,
Doron

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

表情可笑 2024-11-10 20:45:51

我建议使用 windbg (Windows 调试工具,包含在 Windows SDK 中)和 psscor2 更深入地调试您的问题。

基本上,在 windbg 中尝试:

1 .加载 psscor2:

.load C:\tools\psscor2\amd64\psscor2 [替换为放置 psscor2 dll 的路径]

2 . 查找哪些线程持有哪些锁

尝试使用!syncblk

3 。查看正在运行的线程并与持有锁的线程进行比较

!threads

4 。在线程之间切换

~Xs *[其中 X 是您从 !threads 获得的线程 id,并且您对此感兴趣,因为它持有锁]*

  1. 查看当前线程的托管调用堆栈以查找获取锁之前发生了什么

!clrstack -a

编辑:

由于您可能使用的是 .net 4,因此您可能需要使用 SOSEX 而不是 psscor2。到目前为止我还没有真正使用过 SOSEX,但我想看看死锁命令:!dlk

I'd recommend using windbg (Dbugging Tools for Windows, included in the Windows SDK) and psscor2 to debug into your problem a little deeper.

Basically, in windbg try to:

1 . Load psscor2:

.load C:\tools\psscor2\amd64\psscor2 [replace with the path where you put the psscor2 dll]

2 . Try finding which threads are holding what locks using

!syncblk

3 . Look at what threads are running and compare to the threads that are holding locks

!threads

4 . Switch between threads

~Xs *[where X is the thread id you got from !threads and that you are interested in because it's holding a lock]*

  1. look at the managed call stack of the current thread to find out what happened before the lock was acquired

!clrstack -a

EDIT:

Since you're presumably using .net 4, you might want to use SOSEX instead of psscor2. I haven't really used SOSEX so far, but I'd have a look at the deadlock command: !dlk

我ぃ本無心為│何有愛 2024-11-10 20:45:51

一些可能有帮助的提示。我会执行以下步骤:

  1. 右键单击 _lock 并找到所有
    使用 Visual Studio 的参考
    上下文菜单。也许你正在使用
    锁在其他地方(你在更新中做了)。
  2. 确保锁不是静态
    并且 ProductionNode 类不是
    singleton
  3. 您的线程可能是
    被困在里面
    DAL.InsertJobIfNotExists 所以
    记录它的入口和出口
    将有助于追踪问题根源。

Some hints that may help. I would go these steps:

  1. Right click on _lock and find all
    references using Visual Studio
    context menu. Maybe you are using
    the lock somewhere else (you did in your update).
  2. Make sure the lock is not static
    and ProductionNode class is not
    singleton
  3. It is possible your thread is
    trapped inside
    DAL.InsertJobIfNotExists so
    logging it's entrance and exit
    would help tracing the problem root.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文