C＃还具有多处理的概念（除了多线程）吗？
我来自Python编程背景。在Python中，解释器在一个过程中运行。建议对IO操作（文件IO，HTTP请求等）进行多线程，其中建议用于CPU密集操作（计算）进行多处理。
在过程中创建了多个线程的多线程手段。多处理意味着为每个任务创建一个新的过程（解释器）。
我知道C＃还具有异步/等待，任务和任务并行库的概念。看来所有这些多线程（即 - 在同一过程中运行的线程）。那么C＃没有多处理？ C＃中IO与CPU绑定的工作的概念/方法是什么？
I come from python programming background. In python the interpreter runs in a process. Multi threading is recommended for IO operations (file io, http request, etc) where as multi processing is recommended for CPU intensive operations (calculations).
Multi threading means within the processes multiple threads are created. Multi processing means a new process (interpreter) is created for each task.
I understand that C# also has the concept of async/await, Task.Run and Task Parallel library. It appears that these all multi threading (that is - threads running in the same process). So C# does not have multi processing? What is the concept/approach for IO vs CPU bound work in C#?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
两种语言都已完成，因此原则上也可以在另一种情况下完成任何事情！
一个不太陈旧的答案是，不，通常不会诉诸于C＃中的多处理。由于全局解释器锁，添加了Python中的多处理；与其删除该锁的解释器，并在单个Python过程中促进适当的多线程，而是更容易（当时 - Python当时是一个小得多的社区，更少的志愿者等；重要的考虑因素；重要的考虑因素；在需要更少的工作中获得接近相同结果的一些结果。就我而言，最终结果实际上是相当不错的，与演员模型相比，与一个经典的线程更接近演员模型。 [我说“关闭”是因为在演员模型中，一个通常会考虑另一个演员已经存在，
而不是您动态启动的东西 。解释器锁。因此，此运行时间可能使用C＃线程的操作系统线程。因此，它没有内置的演员模型样式多处理类 /库，但是您可以编写自己的文章。像该同类产品的许多其他语言一样，它具有一个线程池，可用于某些操作。
.NET C＃任务并行库（及其数据流库）可以进行Actor模型，因此它将“感觉到”很像Python的多处理，但它并没有催生单独的过程来做到这一点。
Both languages are Turing complete, so in principle whatever can be done in one can also be done in the other!
A less trite answer is that, no, typically one does not resort to multiprocessing in C#. Multiprocessing in Python was added because of the global interpretter lock; instead of ridding the interpretter of that lock and facilitating proper multi-threading within a single Python process, it was easier (at the time - Python was a much smaller community at that time, fewer volunteers, etc; important considerations) to implement multiprocessing and get something close to the same sort of result with less work required. The end result is, so far as I'm concerned, actually quite good, being a lot closer to the Actor model than one classically gets with just threads. [I say "close" because, in Actor model one would normally consider the other Actor to already be there, not something you start up dynamically.]
C# also has a run time interpreter (JIT compiler) but this has no construct like the Global Interpreter Lock. So it's possible for this runtime to use operating system threads for C# threads. So it has no built-in Actor model style Multi Processing classes / library, but you could write your own. Like a lot of other languages of this ilk, it has a thread pool which gets used for some operations.
The .NET C# Task Parallel library (and its DataFlow library) can do Actor model, so it will "feel" a lot like Python's multiprocessing, but it's not spawning up separate processes to do so.