【问题标题】:Costs of a new thread versus cross-thread marshalling新线程与跨线程编组的成本
【发布时间】:2011-03-18 23:36:25
【问题描述】:

所以,我遇到了一个事件发生的情况,然后我需要将它“广播”给几个订阅的“听众”。

我目前的设计是针对每个订阅者的循环,并按顺序工作,依次通知每个“接收者”。

但是,在某些负载/压力测试中,我发现它排队的次数比我喜欢的多

我想提供一种让接收者列表或多或少同时接收通知的方法。

线程池已出。我有自己的理由。

我关心的是性能。 这是我正在考虑的......

A.每次事件触发时,都会为每个接收者创建一个线程来执行接收者特定的通知。通知完成后线程终止。
----或----
B. 事件第一次触发时,为每个接收者创建一个线程,但它是一个“无限”线程(有一个保持其活动的循环),并且通知详细信息被编组到这些线程中的每一个,然后处理新数据.

所以,问题是:创建一个新线程或将数据编组到现有线程是否更昂贵,或者如果同样昂贵,为什么选择一个而不是另一个?

【问题讨论】:

  • 线程池似乎是显而易见的解决方案。你能解释一下为什么它不是一个选项吗?
  • 仅供参考:添加了 .NET 标签,因为这与 C# 无关
  • @Peter - 我更喜欢(在这种情况下)使用线程对象,以便我可以访问线程对象的各种方法/属性。例如,出于调试/支持的原因,我喜欢为我的线程设置一个名称。此外,TP 线程始终是后台,在这种情况下我不想要。

标签: c# .net multithreading broadcasting


【解决方案1】:

创建线程而不是使用 TP 线程在系统资源和时间方面都非常昂贵。例如,通过线程安全队列传递数据可以是高性能的,前提是您没有最大化可用内核(这听起来很可能)并且接收线程阻塞了您发出信号的同步对象。典型的线程上下文切换成本在 2000 到 10,000 个机器周期之间,您可能处于低端,因为线程在相同的地址空间中运行。

真正的代价是很难让这么多线程正确运行而不会无休止地追逐竞争和死锁。

【讨论】:

  • 我现在正在查看一个线程安全队列。我现在想的是创建我自己类型的线程池,根据内核数量进行配给。
  • Hmya,现有的也是这样做的。请关闭您的问题。
  • 好吧,我的问题还没有得到解答。线程创建与将数据编组到正在运行的线程。
  • 我在回答中非常明确地解决了这个问题。如果你不解释为什么这对你来说不清楚,我无法帮助你。自己测量是获得满意和自信答案的更好方法。祝你好运。
  • 我想我希望一个简单的'A'会更好,因为......我认为现在我的问题对于这样的答案的实施来说太主观了。 (这是我关于 SO 的第一个问题 - 如果我关闭这个问题,我可以稍后用我如何解决它/我采取的方向来更新它吗?我希望其他人从这项工作中受益)
【解决方案2】:

您的循环不会造成忙等待问题吗? 大多数循环的迭代都会浪费 CPU 周期,因为它们没有做任何有成效的事情,除了你在循环中进行的一些检查。 我可能会坚持使用新线程,因为拥有空闲 CPU 总是一个糟糕的性能选择。

附:您是否正在实施某种领导者选举算法?

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2020-01-17
    • 2013-01-28
    • 2011-07-30
    • 2012-03-25
    • 1970-01-01
    • 2014-08-15
    • 2010-10-11
    相关资源
    最近更新 更多