线程与基于任务的与异步编程 [英] Threading vs Task-Based vs Asynchronous Programming
问题描述
我是这个概念的新手.这些是相同还是不同的东西?有什么区别?我真的很喜欢能够一次运行两个进程的想法，例如，如果我有几个大文件要加载到程序中，我希望同时加载尽可能多的文件，而不是一次等待一个.而且，当处理大文件(例如wav文件)时，将其切成小块并一次对多个块进行处理，然后将它们放回一起将是很棒的.我想研究什么才能做这种事情?
另外，我知道在多核处理器上使用多个核适合于此，但是显然异步编程并不一定意味着您正在使用多个核?如果没有多个内核可以利用，为什么要这样做?
它们是相关的但有所不同.
线程化，通常称为 multi-threading ，是指在单个进程中使用多个执行线程.这通常是指使用一小组线程的简单情况，每个线程执行需要同时运行或可以从中受益的不同任务.例如，一个GUI应用程序可能有一个线程绘制元素，另一个线程响应鼠标单击等事件，而另一个线程进行一些后台处理.
但是，当每个线程都在做自己的事情的线程数达到极限时，我们通常会开始谈论任务B和任务C都完成时触发任务B->触发任务D等)，而不是必须编写一个大的函数或程序来一个接一个地执行每个任务.当不清楚哪些任务将比其他任务花费更多的时间，以及何时仅松散地耦合任务时，这将提供灵活性.这通常是通过线程池(正在等待分配任务的线程)实现的和一些消息传递界面(MPI)来传达数据和任务合同".
异步编程并不涉及多线程编程，尽管两者经常相互关联(并且可以很好地协同工作).一个 synchronous 程序必须完成每个步骤，然后再继续下一步. 异步程序启动一个步骤，然后继续执行不需要第一步结果的其他步骤，然后在需要第一步结果时检查第一步的结果.
也就是说，同步程序可能会有点像这样:执行此任务"，等到完成"，对结果进行一些处理"以及继续进行其他处理".相比之下，异步程序可能会更像这样:我要开始一个任务，以后我需要结果，但是我暂时不需要它"，与此同时，我ll做其他事情"，直到现在有了第一步的结果，我才能做其他事情，所以，如果还没有准备好，我将等待它"，然后继续进行其他工作".
请注意，异步"指的是非常宽泛的概念，该概念总是涉及某种形式开始一些工作，告诉我什么时候完成"，而不是传统的现在就做！".这不需要多线程，在这种情况下，它只是一种软件设计选择(通常涉及回调函数以及类似的事情，以提供异步结果的通知").使用多个线程，它变得更加强大，因为您可以在异步任务运行时并行执行各种操作.极端地讲，它可以成为更加成熟的体系结构，例如基于任务的方法(这是一种异步编程技术).
我认为您想要的东西更符合另一个概念:并行计算(或并行处理).这种方法更多地涉及将大型处理任务拆分为较小的部分，然后并行处理所有部分，然后合并结果.您应该查看 OpenMP 或OpenCL/CUDA之类的库(对于CPU之前，进行多线程的动机没有那么多，因为收益通常不足以证明开销.
I'm new to this concept. Are these the same or different things? What is the difference? I really like the idea of being able to run two processes at once, for example if I have several large files to load into my program I'd love to load as many of them simultaneously as possible instead of waiting for one at a time. And when working with a large file, such as wav file, it would be great to break it into pieces and do processing on several chunks at once and then put them back together. What do I want to look into to learn how to do this sort of thing?
Edit: Also, I know using more than one core on a multicore processor fits in here somewhere, but apparently asynchronous programming doesn't necessarily mean you are using multiple cores? Why would you do this if you didn't have multiple cores to take advantage of?
They are related but different.
Threading, normally called multi-threading, refers to the use of multiple threads of execution within a single process. This usually refers to the simple case of using a small set of threads each doing different tasks that need to be, or could benefit from, running simultaneously. For example, a GUI application might have one thread draw elements, another thread respond to events like mouse clicks, and another thread do some background processing.
However, when the number of threads, each doing their own thing, is taken to an extreme, we usually start to talk about an Agent-based approach.
The task-based approach refers to a specific strategy in software engineering where, in abstract terms, you dynamically create "tasks" to be accomplished, and these tasks are picked up by a task manager that assigns the tasks to threads that can accomplish them. This is more of a software architectural thing. The advantage here is that the execution of the whole program is a succession of tasks being relayed (task A finished -> trigger task B, when both task B and task C are done -> trigger task D, etc..), instead of having to write a big function or program that executes each task one after the other. This gives flexibility when it is unclear which tasks will take more time than others, and when tasks are only loosely coupled. This is usually implemented with a thread-pool (threads that are waiting to be assigned a task) and some message-passing interface (MPI) to communicate data and task "contracts".
Asynchronous programming does not refer to multi-threaded programming, although the two are very often associated (and work well together). A synchronous program must complete each step before moving on to the next. An asynchronous program starts a step, moves on to other steps that don't require the result of the first step, then checks on the result of the first step when its result is required.
That is, a synchronous program might go a little bit like this: "do this task", "wait until done", "do something with the result", and "move on to something else". By contrast, an asynchronous program might go a little more like this: "I'm gonna start a task, and I'll need the result later, but I don't need it just now", "in the meantime, I'll do something else", "I can't do anything else until I have the result of the first step now, so I'll wait for it, if it isn't ready", and "move on to something else".
Notice that "asynchronous" refers to a very broad concept, that always involves some form of "start some work and tell me when it's done" instead of the traditional "do it now!". This does not require multi-threading, in which case it just becomes a software design choice (which often involves callback functions and things like that to provide "notification" of the asynchronous result). With multiple threads, it becomes more powerful, as you can do various things in parallel while the asynchronous task is working. Taken to the extreme, it can become a more full-blown architecture like a task-based approach (which is one kind of asynchronous programming technique).
I think the thing that you want corresponds more to yet another concept: Parallel Computing (or parallel processing). This approach is more about splitting a large processing task into smaller parts and processing all parts in parallel, and then combining the results. You should look into libraries like OpenMP or OpenCL/CUDA (for GPGPU). That said, you can use multi-threading for parallel processing.
but apparently asynchronous programming doesn't necessarily mean you are using multiple cores?
Asynchronous programming does not necessarily involve anything happening concurrently in multiple threads. It could mean that the OS is doing things on your behalf behind the scenes (and will notify you when that work is finished), like in asynchronous I/O, which happens without you creating any threads. It boils down to being a software design choice.
Why would you do this if you didn't have multiple cores to take advantage of?
If you don't have multiple cores, multi-threading can still improve performance by reusing "waiting time" (e.g., don't "block" the processing waiting on file or network I/O, or waiting on the user to click a mouse button). That means the program can do useful work while waiting on those things. Beyond that, it can provide flexibility in the design and make things seem to run simultaneously, which often makes users happier. Still, you are correct that before multi-core CPUs, there wasn't as much of an incentive to do multi-threading, as the gains often do not justify the overhead.
这篇关于线程与基于任务的与异步编程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
