0

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

我目前的设计是每个订阅者的循环，并连续工作，依次通知每个“接收者”。

然而，在一些负载/压力测试中，我发现它可以比我喜欢的排队更多，在接收器列表中的 #15 可能最终等待很长时间才能收到它的通知。

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

线程池已出。至于为什么，我有自己的理由。

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

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

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

4

2 回答 2

2

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

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

于 2011-03-19T00:43:51.900 回答
0

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

PS您是否正在实施某种领导者选举算法？

于 2011-03-19T00:45:52.147 回答