TPL 任务、线程等
有人可以向我解释一下这些事情是如何关联的吗：
任务
线程
ThreadPool的线程
Paraller.For/ForEach/Invoke
即当我创建一个任务并运行它时，它在哪里获得一个线程来执行？当我调用 Parallel.* 时，幕后到底发生了什么？
任何文章、博客文章等的链接也非常受欢迎！
Could someone clear up to me how these things correlate:
Task
Thread
ThreadPool's thread
Paraller.For/ForEach/Invoke
I.e. when I create a Task and run it, where does it get a thread to execute on? And when I call Parallel.* what is really going on under the covers?
Any links to articles, blogposts, etc are also very welcomed!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
系统的理想状态是每个 CPU 核心有 1 个正在运行的线程。通过用更通用的“任务”术语定义工作，TPL 可以动态地决定要使用多少个线程以及每个线程要执行哪些任务，以便最接近实现理想状态。这些决策几乎总是最好在运行时动态做出，因为在编写代码时，您无法确定应用程序可以使用多少个 CPU 核心、它们在其他工作上的繁忙程度等。
The ideal state of a system is to have 1 actively running thread per CPU core. By defining work in more general terms of "tasks", the TPL can dynamically decide how many threads to use and which tasks to do on each one in order to come closest to achieving that ideal state. These are decisions that are almost always best made dynamically at runtime because when writing the code you can't know for sure how many CPU cores will be available to your application, how busy they are with other work, etc.
线程：是一个真正的操作系统线程，有句柄和ID。
ThreadPool：是已创建的操作系统线程的集合。这些线程由运行时拥有/维护，你的代码只允许“借用”它们一段时间，你只能在这些线程中做短期工作，并且你不能修改任何线程状态，也不能删除这些线程。
对这两个的最佳猜测：
任务：可能在线程池中预先创建的线程上运行，或者可能作为用户模式调度的一部分运行，这完全取决于运行时的想法是最好的。另一个猜测：对于 TPL，用户模式调度不是基于 OS Fiber，而是它自己的完整（和工作）实现。
Parallel.For：实际上，不知道这是如何实现的。运行时可能会创建新线程来执行并行位，或者更有可能使用线程池的线程来实现并行性。
Thread: is a real OS thread, has handle and ID.
ThreadPool: is a collection of already-created OS Threads. These threads are owned/maintained by the runtime, and your code is only allowed to "borrow" them for a while, you can only do work short-termed work in these threads, and you can't modify any thread state, nor delete these threads.
Best guesses on these two:
Task: might get run on a pre-created thread in the thread pool, or might get run as part of user-mode scheduling, this is all depending on what the runtime thinks is best. Another guess: with TPL, the user-mode scheduling is NOT based on OS Fibers, but is its own complete (and working) implementation).
Parallel.For: actually, no clue how this is implemented. The runtime might create new threads to do the parallel bits, or much more likely use the thread pool's threads for the parallelism.