我已经完成了这个 POC 并验证了当您创建 4 个线程并在四核计算机上运行它们时，所有核心都会变得繁忙 - 所以，CLR 已经在不同的核心上有效地调度线程，那么为什么要使用 TASK 类呢？
我同意任务简化了线程的创建和使用，但除此之外还有什么？它只是线程和线程池的包装，对吧？或者它是否以某种方式帮助在多核机器上调度线程？
我专门研究了 2.0 线程中不存在的多核任务。
I have done this POC and verified that when you create 4 threads and run them on Quad core machine, all cores get busy - so, CLR is already scheduling threads on different cores effectively, so why the class TASK?
I agree Task simplifies the creation and use of threads, but apart from that what? Its just a wrapper around threads and threadpools right? Or does it in some way help scheduling threads on multicore machines?
I am specifially looking at whats with Task wrt multicore that wasnt there in 2.0 threads.
发布评论
评论（3）
这还不够吗？它提供了更高级别的构建块，以便我们凡人可以构建安全的无锁多线程代码，这不是很棒吗，因为像 Joe Duffy 这样的聪明人有为我们做了工作吗？
如果 TPL 真的只是一种开始新任务的方式，那么它就没有多大用处——工作窃取等很好，但对我们大多数人来说可能并不重要。它是围绕任务的构建块 - 特别是围绕“未来”的想法 - 提供了价值。您真的想自己编写
Parallel.ForEach吗？您想亲自了解如何有效地执行分区吗？我知道，如果我尝试这样做，我会花费很长时间，而且我肯定会比 PFX 团队做得更差。开发中的许多进步并不是为了让以前不可能完成的事情成为可能，而是为了提高抽象级别，以便问题可以一次性解决，然后再解决该问题重复使用。您对 CLR 本身也有同样的感觉吗？显然，您可以自己在汇编中做同样的事情...但是通过提高抽象级别，CLR 和 C# 使我们的工作效率更高。
Isn't that enough? Isn't it fabulous that it provides higher-level building blocks so that us mere mortals can build lock-free multithreaded code which is safe because really smart people like Joe Duffy have done the work for us?
If TPL really just consisted of a way of starting a new task, it wouldn't be much use - the work-stealing etc is nice, but probably not crucial to most of us. It's the building blocks around tasks - and in particular around the idea of a "future" - which provide the value. Do you really want to write
Parallel.ForEachyourself? Do you want to want to work out how to perform partitioning efficiently yourself? I know that if I tried doing that, it would take me a long time and I'd certainly do a worse job of it than the PFX team.Many of the advances in development haven't been about making it possible to do something which was impossible before - they've been about raising the abstraction level so that a problem can be solved once and then that solution reused. Do you feel the same way about the CLR itself? You could do the same thing in assembly yourself, obviously... but by raising the abstraction level, the CLR and C# make us more productive.
尽管您可以在 TPL 或线程池中等效地完成所有操作，但为了更好的抽象和可扩展性模式，TPL 优于线程池。但这取决于程序员，如果您确切地知道自己在做什么，并且根据特定应用程序中的调度和同步要求，您可以更有效地使用线程池。使用 TPL 可以免费获得一些东西，但在使用 Threadpool 时必须对其进行编码，例如我现在能想到的以下几个。
Although you could do everything equivalently in TPL or threadpool, for a better abstraction, and scalability patterns TPL is preferred over Threadpool. But it is upto the programmer, and if you know exactly what you are doing, and based on your scheduling and synchronization requirements play out in your specific application you could use Threadpool more effectively. There are some stuff you get free with TPL which you've got to code up when using Threadpool, like following few I can think of now.
TPL 允许您根据任务而不是线程进行编程。仅将任务视为更好的线程抽象是错误的。任务允许您指定要执行的工作，而不是指定工作执行方式（线程）。这允许您表达应用程序的潜在并行性，并让 TPL 运行时（调度程序和线程池）处理该工作的执行方式。这意味着 TPL 将为您减轻很多负担，让您的应用程序确保在具有不同内核数量的各种硬件上获得最佳性能。
例如，TPL 可以轻松实现几个关键的设计模式，使您能够表达应用程序的潜在并行性。
http://msdn.microsoft.com/en-us/library/ff963553.aspx
就像 Futures（Jon 提到的）以及管道和并行循环。
The TPL lets you program in terms of Tasks not threads. Thinking of tasks solely as a better thread abstraction would be a mistake. Tasks allow you to specify the work you want to get executed not how you want the work executed (threads). This allows you to express the potential parallelism of your application and have the TPL runtime--the scheduler and thread pool--handle how that work gets executed. This means that the TPL will take a lot of the burden off you of having your application deal with ensuring the best perfromance on a wide variety of hardware with different numbers of cores.
For example, the TPL makes it easy to implement key several design patterns that allow you to express the potential parallelism of your application.
http://msdn.microsoft.com/en-us/library/ff963553.aspx
Like Futures (mentioned by Jon) as well as pipelines and parallel loops.