.NET 4.0 线程池有哪些改进？
我正在阅读一本 C# 4.0 书，其中给出了线程池最大线程限制的以下默认值。
- 32 位环境中的 Framework 4.0 中为 1023
- 64 位环境中的 Framework 4.0 中为 32768
- Framework 3.5 中每个核心为 250 Framework
- 2.0 中每个核心为 25
谁能告诉我什么可能导致默认值大幅增加，特别是64 位？上下文切换的问题解决了吗？
过去，我们对线程池的大小设置了合理的限制，因为似乎存在一个最佳点，之后我们的应用程序会因上下文切换而变慢。当然，我们会在更新目标框架后进行压力测试和重新基准测试。但是谁能透露一下为了实现更大的线程池而进行了哪些框架改进呢？或者只是微软增加了默认值以使其看起来令人印象深刻？
I am reading a C# 4.0 book which gives the following default values for the maximum thread limit for the threadpool.
- 1023 in Framework 4.0 in a 32-bit environment
- 32768 in Framework 4.0 in a 64-bit environment
- 250 per core in Framework 3.5
- 25 per core in Framework 2.0
Can anyone tell me what might might have prompted such a vast increase in the defaults, especially for 64 bit? Have the issues with context switching been solved?
In the past, we have set reasonable limits on the size of the threadpool because there seems to be a sweet-spot, after which our application slows down due to context switching. Naturally, we will stress test and re-benchmark after updating the target framework. But can anyone shed any light on what framework improvements have been made to enable a larger threadpool? Or is it just MS increasing the defaults to look impressive?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
上下文切换的问题尚未解决（由于其本质属于操作系统）。但是，当您使用 ThreadPool 采取正确的方式（异步）时，上下文切换就不是问题了。由于新的 TPL 和它必须解决的一些其他需求，.NET ThreadPool 调度程序得到了改进。
尝试从 CLR 4.0 线程池改进
另请检查：限制 CLR 中的并发4.0 ThreadPool 和这个 很棒的视频
Issues with context switching was not solved (due to its nature belongs to OS). But when you go right way (async) with ThreadPool context switches are not an issue. .NET ThreadPool scheduler was improved due new TPL and some other needs it have to solve.
Try to start with CLR 4.0 ThreadPool Improvements
Also check: Throttling Concurrency in the CLR 4.0 ThreadPool and this great video
它经过调整，可以更好地在现代大铁上工作。具有超过 64 个 CPU 核心的机器，这种硬件。显然，他们在上下文切换方面遇到的麻烦更少。他们添加到调度程序的反馈循环很有趣，可以收集统计数据以做出更好的调度决策。但只有在您首先获得主要硬件之后，这些东西才会发挥作用。
It was tweaked to work better on modern Big Iron. Machines with more than 64 CPU cores, that kind of hardware. Obviously they have less trouble with context switches. The feedback loop they added to the scheduler is interesting, gathering statistics to make better scheduling decisions. But this stuff doesn't kick in until you've got the major hardware first.