新线程与跨线程编组的成本
因此，我遇到一个事件发生的情况，然后我需要将其“广播”给几个订阅的“听众”。
我当前的设计是每个订阅者的循环并串行工作，依次通知每个“接收者”。
然而，在一些负载/压力测试中，我发现它排队的时间比我喜欢的要多，接收器列表中的#15可能最终会等待很长时间才能收到通知。
我想提供一种方法，让接收者列表或多或少同时接收通知。
线程池已经出来了。我有我自己的理由。
我关心的是性能。 这是我正在考虑的......
A. 每次事件触发时，都会为每个接收器创建一个线程来执行接收器特定的通知。通知完成时线程终止。
----或----
B. 事件第一次触发时，会为每个接收者创建一个线程，但它是一个“无限”线程（有一个使其保持活动状态的循环），并且通知详细信息将编组到每个线程，然后由这些线程处理新数据。
因此，问题是：创建新线程或将数据封送到现有线程是否更昂贵，或者如果同样昂贵，为什么选择其中一个而不是另一个？
So, i have a situation where an event occurs and i need to then 'broadcast' that to several subscribed 'listeners'.
My current design is a loop for each subscriber and works serially, notifying each 'receiver' in turn.
However, in some load/stress testing i find that it can queue up more than i like in that #15 in a list of receivers could end up waiting a long time before it receives it's notification.
I want to provide a way to have the list of receivers receive the notification more or less concurrently.
ThreadPool is out. I have my own reasons as to why.
My concern is on performance.
Here is what I'm considering....
A. Each time the event fires, one thread is created for each receiver to do the receiver specific notification. The thread dies when the notification completes.
----OR----
B. The first time the event fires, a thread is created for each receiver, but is an 'infinite' thread (has a loop that keeps it alive), and notification details are marshaled to each of these threads which then process the new data.
So, the question is: Is it more expensive to create a new thread, or to marshal data to an existing thread, or if equally expensive, why choose one over the other?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
创建线程而不是使用 TP 线程在系统资源和时间方面都相当昂贵。例如，通过线程安全队列传递数据可以是高性能的，前提是您没有最大化可用核心（这听起来很可能）并且接收线程阻塞在您发出信号的同步对象上。典型的线程上下文切换成本在 2000 到 10,000 个机器周期之间，您可能处于低端，因为线程在相同的地址空间中运行。
真正的成本是让如此多的线程正确运行而不无休止地追逐竞争和死锁的难度。
Creating a thread instead of using a TP thread is quite expensive, both in system resources and time. Passing data through, say, a thread-safe queue can be performant, provided you haven't maxed out the available cores (which sounds very likely) and the receiving thread is blocking on a synchronization object that you signal. Typical thread context switch cost is between 2000 and 10,000 machine cycles, you are probably on the low end since the thread runs in the same address space.
The real cost is the difficulty of getting so many threads to run correctly without endlessly chasing races and deadlocks.
你的循环不会造成繁忙等待问题吗？
大多数循环的迭代都会浪费 CPU 周期，因为除了循环中的一些检查之外，它们不会做任何有成效的事情。
我可能会坚持使用新线程，因为拥有空闲 CPU 始终是一个糟糕的性能选择。
PS 您是否正在实施某种领导者选举算法？
Doesn't your loop create a busy waiting problem?
Most of the loop's iterations are going to waste CPU cycles since they don't do anything productive, except a couple of checks that you have in the loop.
I would probably stick to new thread since having an idle CPU is always a bad performance choice.
P.S. Are you implementing some sort of a leader election algorithm?