我正在编写一个服务器应用程序来处理来自多个客户端的请求。对于请求的处理，我使用的是线程池。
其中一些请求修改了数据库记录，我希望一次将对该特定记录的访问限制为一个线程池线程。为此，我使用命名的信号量(其他进程也在访问这些记录)。
对于每个想要修改记录的新请求，线程应该排队等候轮到它。
这就是问题所在:
因为我不希望线程池被等待访问记录的线程填满，所以我在线程池中找到了RegisterWaitForSingleObject方法。
但是当我阅读备注部分下的文档(MSDN)时:
New wait threads are created automatically when required. ...
这是否意味着线程池 将充满等待线程？这对线程池的性能有何影响？
我们非常欢迎任何其他提升性能的建议!
谢谢!
最佳答案
您的解决方案是一个可行的选择。在没有更具体的细节的情况下，我认为我无法提供其他有形的选择。但是，让我试着说明为什么我认为您当前的解决方案至少是基于合理的理论。
假设您同时收到 64 个请求。可以合理地假设线程池可以立即将这些请求中的每一个分派(dispatch)给一个线程。因此，您可能有 64 个立即开始处理的线程。现在让我们假设互斥量已经被另一个线程获取并且它被持有了很长时间。这意味着这 64 个线程将被阻塞很长时间，等待当前拥有互斥锁的线程释放它。这意味着这 64 个线程被浪费在无所事事上。
另一方面，如果您选择使用 RegisterWaitForSingleObject 而不是使用阻塞调用来等待互斥锁被释放，那么您可以立即释放这 64 个等待线程(工作项)并且让他们放回游泳池。如果我要实现我自己的 RegisterWaitForSingleObject 版本，那么我会使用 WaitHandle.WaitAny 方法，它允许我指定最多 64 个句柄(我没有随机选择 64毕竟请求的数量)在单个阻塞方法调用中。我并不是说这很容易，但我可以用池中的一个线程替换我的 64 个等待线程。我不知道 Microsoft 是如何实现 RegisterWaitForSingleObject 方法的，但我猜他们以至少与我的策略一样有效的方式实现了这一点。换句话说，您应该能够通过使用 RegisterWaitForSingleObject 将线程池中待处理工作项的数量至少减少 64 倍。
所以你看，你的解决方案是基于合理的理论。我并不是说您的解决方案是最优的，但我确实相信您对所提出的具体问题的担忧是没有根据的。
关于c# - ThreadPool RegisterWaitForSingleObject 的资源使用，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5684087/