.net - 基于消息的多线程或线程池用于简短且不常见的操作？

Question

我目前在 .NET 中使用 Retlang 进行基于消息的多线程处理，这是一个很棒的库。我不再有显式锁，每个线程都在做自己的事情，管理它自己的应用程序部分并通过消息与其他线程通信。

我现在必须实现我的应用程序的一个功能，它也可以有自己的发布者/订阅者线程。唯一的问题是这个线程实际上做的工作很少。预计每 10 分钟左右从发布者收到一条消息。收到消息后，它会做一些工作，但不会超过几百毫秒。

所以我开始怀疑让一个线程在 99.9% 的时间里休眠是否真的是一个不错的选择。有用于此类操作的线程池，但由于我无法控制接收消息的线程，因此我不得不求助于丑陋且容易出错的锁。

我的问题是:从资源方面来说，让线程闲置并等待绝大部分时间真的是个问题吗？在使用良好的基于​​消息的架构之后使用共享多线程感觉就像回到过去，而且它将是应用程序中唯一带锁的部分。但我一直想知道“我在这里做错了什么吗？”用这个线程。

编辑:谢谢大家，在阅读了您的每一个回答后，我认为另一个线程不是什么大问题。我的应用程序将仅与基于消息的多线程保持一致，如果我真的遇到性能问题(但不应该是这种情况)，我将进一步调查。

Answer 1

我实际上认为，将 ThreadPool 用于大部分时间处于休眠状态的线程是一个糟糕的设计选择 -

让一个线程休眠(或者，更好的是，等待一个事件)在您的应用程序中的开销很小。使用专用线程的主要缺点是线程需要分配自己的堆栈，因此与线程池线程相比，您将使用一些额外的内存。