“重线程环境”的定义是什么？
我在一段代码上使用锁。尽管临界区很小，但许多线程会到达那里（大约每秒 100 个线程）。在一些文章中，我看到此方法不适合繁重的线程环境。
我的问题是我们称之为重线程环境的速率是多少？
I'm using a lock over a section of code. Although the critical section is small, many threads would reach there (about 100 threads per second). In some articles I see this method is not suitable for heavy threading environments.
My question is at what rate we call an environment heavy threaded ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不幸的是，我认为重线程没有任何具体的数字定义。一些快速的谷歌搜索向我展示了最近的上下文切换基准数字，引用上下文切换成本介于 1us 和 30us。悲观地假设 30us，这意味着：
每秒执行您提到的 100 次上下文切换。不用担心，但上下文切换并不是全部：您还必须考虑互斥体争用的成本，我建议在您自己的应用程序中以及您正在使用的特定互斥体实现中进行测量。
最重要的是，如果您的应用程序获得了可接受的吞吐量，那么以这些速率使用此模式就可以了。我的猜测是，互斥锁争用可能占主导地位，因此关键部分的运行时间（以及运行时间的可变性）可能会决定是否为您工作。
Unfortunately, I don't think there's any specific, numerical definition of heavy threaded. Some quick Googling showed me recent context switch benchmark numbers quoting context-switching costs as somewhere between 1us and 30us. Pessimistically assuming 30us, this means:
for doing the 100 context switches per second you mention. No worry there, but context switches aren't the whole story: you'll also have to consider the costs of mutex contention, which I'd recommend measuring in your own application and with the specific mutex implementation you're using.
The bottom line is that if you get acceptable throughput for your app, it's fine to use this pattern at these rates. My guess is that mutex contention is likely to dominate, and thus that the running time (and variability of running time) of your critical section could make the difference between this working for you and not working for you.