用await不就好了?
TAP的正确用法就是await,await说白了就是编译器帮你把代码翻译成callback形式。
异步当然绕不开重入,重入的实现就是callback,没什么不好理解的。
Task原本是设计给TPL用的,后来搞async的时候懒得搞IPromise了就直接把Task拿来用了。
======================================================
这里稍微补充一下异步方法能不能没有返回值的问题。
按照微软的说法是,允许无返回值方法作为异步方法是一个遗留问题,因为大部分的EventHandler都是无返回值的。如果不允许的话,就会多一些没什么卵用的代码来抛弃返回的Task对象:
public void EventHandler( object sender, EventArgs e ) { DoSomethingAsync();//returns a Task }
事实上无返回值的异步方法和上面这个包装是一样的,就是把Task扔掉仅此而已。
但实际上来讲,无返回值方法作为异步方法,或者说抛弃返回的Task并不是一件不可饶恕的事情。在特定场景下是可以用的,需要满足两个特定的条件:
1、异步方法没有返回值给调用方。
2、调用方压根儿不关心异步方法调用成功与否以及何时完成。
当然,没有返回值也意味着异常无法向外传播,所以方法内最好将异常全部处理完毕。
看了下面的答案,大部分是对的,但也有很多细节有问题。
异步与否与多线程没有必然的关系,Task会在哪个线程执行,完全取决于TaskScheduler,在当前线程直接执行也不是完全不可能的事情。假定异步操作或者Task一定会在另一个线程执行是不正确的。
TAP几乎唯一正确的使用方式就是直接用await,UI线程可以直接用await。当然,你可以认为await本质上也就是ContinueWith的语法糖,但是await可以帮你处理的情况远比你自己写一坨翔好得多。说await只是将代码切成两份未免太天真,考虑下面的代码:
async Task DoAsync() { while( true ) { Console.WriteLine( DateTime.Now ); await Task.Delay( 100 ); } }
await可以把这段代码切成无限多份。
这也是编译器为啥要用状态机的原因,状态机只是实现,具体的实现方式可以有很多种。