在同步中花费的线程时间是否过高?

Joe*_*eky 7 c# concurrency performance multithreading micro-optimization

今天,我使用Visual Studio 2010性能分析器分析了我的一个C#应用程序.具体来说,我正在对" 并发 " 进行概要分析,因为看起来我的应用程序应该具有更多的容量然后才能进行演示.分析报告显示,线程在同步状态下花费了大约70-80%的时间.

说实话,我不确定这意味着什么.这是否意味着应用程序遭受了锁定状态?

对于上下文...有大约30个+长时间运行的线程绑定到单个AppDomain(如果这很重要)并且一些线程非常繁忙(例如while(true) { _waitEvent.WaitOne(0); //do stuff }).

我意识到这是一个相当模糊的问题......我想我正在寻找关于线程同步状态含义的一些说明.太多了,为什么?~75%真的很糟糕吗?我有太多线程吗?或者我应该开始寻找其他领域?

Eri*_*ert 15

我不确定这意味着什么.

这意味着线程平均花费75%的时间等待另一个线程完成一些工作.

这是否意味着应用程序遭受了锁定状态?

也许!

为不熟悉术语的读者澄清:"死锁"是指两个线程都在等待彼此完成,因此他们会永远等待."实时锁定"是两个线程试图避免死锁的情况,但由于选择不当,无论如何都要花大部分时间等待.想象一下,例如一张有两个人的桌子,一把叉子和一把刀.两个人都希望拿起两个器具,使用它们,然后放下它们.假设我拿起刀子你拿起叉子.如果我们都决定等待对方放下器具,我们就陷入僵局.如果我们都意识到我们即将陷入僵局,我放下刀子,你放下叉子,然后我拿起叉子然后拿起刀子,我们就锁定了.我们可以无限期地重复这个过程; 我们都在努力解决这个问题,但我们没有足够的沟通来实际快速解决问题.

但是,我的猜测是你没有处于锁定状态.我的猜测是,您只需要对少量关键资源进行大量争用,这些资源一次只能由一个线程访问.Occam的Razor表明你应该假设一个简单的假设 - 许多线程轮流使用稀缺资源 - 而不是复杂的假设 - 一大堆线程都试图告诉对方"不,你先走".

有大约30个长时间运行的线程绑定到单个AppDomain(如果这很重要)并且一些线程非常繁忙(例如,(true){_ waitEvent.WaitOne(0); // do stuff}).

听起来很可怕.

我意识到这是一个相当模糊的问题.

是的.

太多了,为什么?

好吧,假设你正试图穿越城镇,你和城里的其他所有司机花了75%的时间停在交通灯等待其他司机.你告诉我:那太多了,为什么?花一个小时的交通来驾驶15分钟的距离可能是一些人完全可以接受的,而其他人完全不能接受.每次我在高峰时间乘坐SR 520,我都要花一个小时的时间来移动距离,这需要15分钟.这是我不能接受的,所以现在我坐公共汽车.

您和您的客户是否接受这种糟糕的性能是您的号召.修复性能问题很昂贵.您应该问的问题是,通过承担诊断和解决问题的费用,您将获得多少利润.

~75%真的很糟糕吗?

你的线程花费的时间比他们需要的时间长四倍.对我来说似乎不太好.

我有太多线程吗?

你几乎可以肯定,是的.30很多.

但在您的情况下,这完全是错误的技术问题.问"我有太多线程吗?" 通过询问" 这个城市有太多的汽车吗? " 试图解决交通拥堵问题.正确的问题是" 为什么这个城市有可能有高速公路的交通灯这么多? "问题不在于线程; 问题是他们正在等待而不是停下来直到他们的目的地.

我应该开始寻找其他领域吗?

我们怎么知道呢?

  • 我还在考虑你的答案......但是......说实话.我很欣赏你的直率,并在阅读时大笑.谢谢...说得好! (2认同)
  • @JoeGeeky:高同步数表示程序没有有效地使用多核机器的处理能力.那是一件坏事?这取决于你的客户,谁支付,比如说,四核机器,将接受获得单核机器的性能.大多数客户希望购买更多内核可以获得更高的性能; 你可能会让他们失望. (2认同)