在没有线程或异步设备的情况下，异步/等待模式是否无关紧要? [英] Is async/await pattern irrelevant without threading or asynchronous devices?

问题描述

编辑-阅读以下三个答案后，我意识到我在问废话！很抱歉浪费您的宝贵时间，并感谢您澄清了许多误会！ :)

Edit - After reading the three answers below, I've realized that I'm asking nonsense ! Apologies for wasting some of your precious time, and thanks for clarifying alot of misunderstandings, really! :)

我假设苹果和管钳在async/await和线程是解决类似问题的方式中是同一回事关注. Async/await和Threads都解决了UI响应性，但方式不同.前者是一种模式，当可以异步收集多个所需结果时(例如，为了改善用户体验)，将使用这种模式，因此将其称为异步".繁重的工作，需要花费几秒钟到几小时的工作，必须卸载到另一个线程上，以保持UI响应速度.这两个是完全不同的问题.

I were assuming apples and pipe wrenches were the same thing in the way async/await and threads are solution for similar concerns. Async/await and Threads both addresses UI responsiveness, but not in the same way. The former is a pattern to be used when several desired results can be gathered asynchronously (in order to improve user experience for example), hence why it's called "async". Heavy works, those that take several seconds to hours has to be off loaded on another thread to keep UI responsive. Those two are completely different concerns.

无论我如何编辑此问题，都无法通过线程问题来询问这样的异步/等待，因为它们是完全不同的东西，可以一起使用(以多种方式使用)或单独使用.下面的.2语句说明了一切(除了一个调用"误解)，但是我从一开始就并没有真正理解它的真正含义.

No matter how I may edit this question, there is no way to ask such async/await with or without threading concern as they are completely different things, can be used together (in so many ways) or separately. The statement .2 below said it all (apart a "invocation" misconception) but I didn't truely understood its true meaning from the start.

我想我应该从怀疑的那一刻起就删除这个问题，但是在实际阅读一些答案之前，我无法理解这是一个愚蠢的问题.但是，这也可能有助于其他人更好地了解异步/等待的含义.

I guess I should have deleted the question from the moment I had doubts, but I couldn't understand how far it was a dumb one before actually reading some answers. However, this may also help other to have a better understanding of what async/await is about.

_{顺便说一句，我不知道将什么答案标记为答案，因为它们都具有有价值的信息.}

原始帖子:

请注意我是还有另一个异步/等待初学者" .但是，到目前为止，我了解的是:

It's fair to note that I'm "yet another async/await beginner". However, What I've understood so far are:

1. 异步/等待不会创建threads！绝不 ！它们在与调用方相同的线程上运行.
2. 异步/等待不是并行任务.他们只是定义了一种模式，在调用者级别调用await时，将执行异步代码块(或者-我知道我的理解有点错误，但这是我可以清楚地看到它的方式)
3. 如果该代码块不包含await关键字，则不会异步执行该代码块.
4. async/await似乎可以很好地处理某些I/O任务，但在大多数CPU较高的计算上似乎并不那么出色.
5. async/await似乎在Thread.Sleep上失败(应该使用Task.Delay代替)，或者在Exception上使用Finally块的情况下失败.

1. async/await doesn't create threads ! Never ! They run on the same thread as the caller.
2. async/await are not parallel tasks. They just defines a pattern where an async block of code get executed the moment an await is invoked at caller level (or so - I know my understanding is slightly wrong, but that's how I can clearly picture it in mind)
3. No code block is executed asynchronuously if that block doesn't contain an await keyword.
4. async/await appears to work well with some I/O tasks, but seems not that wonderful on most high CPU computations.
5. async/await seems to fail with Thread.Sleep (should use Task.Delay instead) or in case of Exception with Finally block.

基于上述内容，并且为了简化起见，我认为async/await只是 goto 的一种改进形式，能够从一个方法步骤跳转到另一个方法步骤，因为goto呼叫可以飞行"(被延迟)，直到遇到等待！ (很抱歉，目前为止无法简化)

Based on the above, and to simplify things, I think async/await is just an improved form of goto, capable of jumping from a method step to another method step, because the goto call can "fly" (be delayed) until an await is encountered ! (sorry to simplify things that far)

我已经在没有额外线程的情况下测试了I/O和CPU代码，这两个线程都很笨重，并且都产生了无响应用户界面，直到一切完成为止.

I've tested both I/O and CPU codes without additional threads, both heavy, and both produced unresponsive UI until everything was completed.

我的观察力是:

没有具有异步功能的东西:

• 使用框架中众多.net对象之一或由其自己创建线程的成员明确定义的线程
被设计为从一开始就在硬件级别(CPU)异步运行的
• 或IO devices

• threads explicitely defined using one of the numerous .net objects in the framework, or their members that create threads on their own
• or IO devices that are designed to work asynchronously from the start at hardware level (CPU)

async/await只是普通的同步模式；意思是，只有async/await关键字在任何地方都没有类似异步的东西.

async/await are just plain synchronous patterns; meaning, there is no asynchronous-like thing anywhere with just async/await keywords.

问题是:以上观察是正确的，还是我错过了有关async/await的一些重要内容?

The question is: is the above observation true, or am I missing some important thing about async/await ?

---

旁注:

---

Side notes :

_{我已阅读此博客文章(没有线程，Stephen Cleary的博客).他指出，没有线程(完全同意)，但是这与我的观察结果并不矛盾，在纯程序员代码级别上，如果不涉及异步设备，则除非您将繁重的任务委派给另一个线程，否则您将没有响应式UI.我所关心的不是模式的 awaitable 方面，就像我说的那样，它就像是飞翔的goto.我想确保我不会只是为了使用新东西而盲目使用async/await.}

_{I've read this blog post (There Is No Thread, Stephen Cleary's Blog). He states that there is no thread (totally agree) but it doesn't contradict with my observation that, at pure programmer code level without asynchronous devices involved, you can't have a responsive UI unless you delegate the heavy tasks in another thread. My concern is not the awaitable aspect of the pattern, as I said, it's like a flying goto; I want to make sure I'm not using async/await blindly just for the sake of using something new.}

_{.ConfigureAwait(false):对我来说似乎涉及ThreadPool，这就是UI线程仍然响应的原因...}

_{.ConfigureAwait(false) : seems to involve a ThreadPool to me, which is why the UI thread is still responsive...}

推荐答案

Async-await是一种模式，允许您编写与同步代码极为相似但实际上可以异步执行的代码.这依赖于编译器完成的许多工作.就是这样.

Async-await is a pattern that allows you to write code that closely resembles synchronous code but can actually execute asynchronously. This relies on a lot of work done by the compiler. That's all.

Async-await不会创建异步操作，它仅允许您以简单的方式使用它们，并且仍然是异步的，这与使用BeginXXX/EndXXX之前的操作不同.

Async-await doesn't create asynchronous operations, it just allows you to use them in a simple way and still be asynchronous, unlike before using BeginXXX/EndXXX.

的确，异步对于I/O最为有用，因为大多数异步操作都是I/O操作，但是还有其他不同的操作，例如Task.Delay，异步同步机制或异步等待事件.

It's true that async is mostly useful with I/O, because most asynchronous operations are I/O operations, but there are different ones like Task.Delay, asynchronous synchronization mechanisms or asynchronously waiting for an event.

关于您的具体观点:

1. 异步等待不会创建线程.异步方法开始在调用者线程上运行，不要将任何线程用于实际的异步操作，并在ThreadPool线程或由SynchronizationContext或TaskScheduler定义的线程上恢复. li>
2. 未调用等待.当异步方法等待未完成的任务时，该方法的其余部分将作为该任务完成时将要运行的继续进行调度.
3. 差不多.您需要等待异步操作，异步方法才能异步.
4. 异步等待与两者一起使用.如果您的操作不是异步的，则使用async-await没有任何意义.
5. 异步等待不会因Thread.Sleep而失败.使用Thread.Sleep只是浪费，因为它阻塞了线程.这就是为什么使用Task.Delay的原因.现在，您可以使用C#6在finally中等待.

1. Async-await doesn't create threads. Async methods start running on the caller thread, don't use any thread for the actual asynchronous operation and resume on a ThreadPool thread or one defined by the SynchronizationContext or TaskScheduler.
2. Await isn't invoked. When an async method reaches an await on an uncompleted task the rest of the method is scheduled as a continuation that will run when that task is completed.
3. Pretty much. You need to await an asynchronous operation for your async method to be asynchronous.
4. Async-await works with both. If your operation isn't asynchronous though, there's no point in using async-await.
5. Async-await doesn't fail with Thread.Sleep. It's just wasteful to use Thread.Sleep as it blocks a thread. That's why you use Task.Delay. You can now await in finally with C# 6.

最后:

意思是，只有async/await关键字在任何地方都没有类似异步的东西.

meaning, there is no asynchronous-like thing anywhere with just async/await keywords.

是的，使用async关键字标记方法不会使任何内容异步运行.它仅允许您使用await并将结果包装在Task中.

Yes, marking a method with the async keyword doesn't make anything run asynchronously. It only allows you to use await and wrap the result in a Task.

这篇关于在没有线程或异步设备的情况下，异步/等待模式是否无关紧要?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！