Windows 中每个进程/线程的最大互斥量
Asp.net 应用程序中每个进程/线程的最大互斥量是否有限制？
以防万一目标操作系统是：Windows XP Pro、服务器 2003/2008 和不久的将来的 Windows 7。 通常网站部署在应用程序池中。
Is there a limit in the maximum number of mutexes per process/thread in a Asp.net application?
Just in case the target operating systems are: Windows XP Pro, server 2003/2008 and Windows 7 in the near future.
Usually the website is deployed in an App Pool.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
该限制本质上与进程可以拥有的句柄数量的限制相同。这是一个相当大的数字：16,777,216。当然，真正的限制要低得多，并且取决于您有多少可用的非分页池，这并不是那么大。
如果您担心该限制，则说明您的程序有问题。请记住，临界区通常会延迟任何内核对象的创建，这意味着如果争用很少，您可以拥有大量内核对象。
The limit is essentially the same as the limit on the number of handles a process can have. It's quite a big number: 16,777,216. Of course, the real limit is much lower, and depends on how much non-paged pool you have available, which isn't that big.
If you're worried about the limit, there's something wrong with your program. Keep in mind that critical sections usually delay the creation of any kernel objects, which means you can have a large number of them if there are few contentions.
我要冒着风险，冒着你可能（不一定）做错事的可能性。
Raymond Chen 说过最好但是，如果如果您担心互斥体的最大数量，您可能会以太细的粒度保护您的资源。
当然，会有一个最大数量，即使它是由可用内存而不是常数决定的。但是，我看不到任何有效的情况，您需要如此多的互斥体，以致达到极限。
我并不是说这是不可能的，因为我不知道您的应用程序的架构是什么。但如果没有更好的方法，我会感到非常惊讶。
也许如果您退一步告诉我们“我想要什么”而不是“我是如何做到的”，我们可以提供更好的建议。
I'm going to go out on a limb here and venture the possibility that you're probably (not necessarily) doing something wrong.
Raymond Chen said it best but, if you're worried about the maximum number of mutexes, you're probably protecting your resources at too fine a granularity.
Certainly there will be a maximum number even if it's dictated by available memory rather than a constant. However, I can't see any valid situation in which you would need so many mutexes that you would hit a limit.
I'm not saying it's not possible since I have no idea what the architecture of your application is. But I would be very surprised if there wasn't a better way to do it.
Perhaps if you step back and tell us the "what I want" rather than the "how I did it", we could offer better advice.