如何正确实现async yielding 自定义异步场景的等待点实现方案

内置IO异步方法的实现原理 #

.NET 中所有文件、网络相关的内置异步API，底层都没有占用线程池线程做阻塞等待，核心是依赖 操作系统原生异步IO机制 + 回调通知 实现，完整流程如下：

• 同步执行阶段：方法被调用后全程在调用方的线程上下文里运行，完成参数校验、IO请求初始化等前置工作，没有任何线程切换
• 提交IO请求：调用对应平台的内核异步接口（Windows 用 IOCP，Linux 用 epoll/io_uring，macOS 用 kqueue），把IO请求提交到内核的IO队列，此时用户态的同步执行路径就走到头了
• 内核处理阶段：IO请求处理完成前，完全不会占用任何用户态线程，不存在线程阻塞的问题
• 延续调度：IO完成后，操作系统会通过预先注册的回调通知.NET运行时，运行时再把方法的后续延续逻辑投递到对应的同步上下文（没有同步上下文时默认投递到线程池）执行

自定义无阻塞异步方法的最优实现 #

如果你的等待逻辑没有现成的内置IO API可以复用，分两类场景选择实现方案：

场景1：等待逻辑基于内核级硬件/IO事件 #

这是最标准的异步场景，你只需要实现平台适配的粘合层即可：

1. 调用方触发方法后，先在当前线程上下文完成所有前置校验、资源准备工作
2. 调用对应平台的内核异步接口提交请求，同时创建一个未完成的Task/ValueTask实例返回给调用方
3. 绑定内核IO完成回调，回调触发时自动通知对应的Task进入完成状态，运行时会自动调度后续的延续逻辑
   这种实现完全符合你要求的「让出控制权之前全程在调用方上下文运行、无额外线程开销」的标准，完全不需要调用Task.Run或者Task.Yield。

场景2：等待逻辑是用户态自定义事件/信号 #

如果你的等待逻辑不涉及内核IO，只是要等用户态的自定义事件、调度信号等，直接用TaskCompletionSource（简称TCS）实现即可：

1. 先在当前线程上下文完成所有前置工作
2. 实例化一个TCS对象，给你要等待的自定义事件注册回调，回调触发时调用TCS.SetResult()/TCS.SetException()标记任务完成
3. 直接返回TCS.Task给调用方即可
   这种实现同样不会阻塞调用线程，也没有额外的线程开销，控制权在你返回未完成的Task时就自动交还给了调用方。

关于Task.Yield的常见误区 #

Task.Yield的作用是强制让当前async方法立刻让出控制权，把剩余逻辑作为延续任务调度执行，它的底层实现非常简单：返回一个固定IsCompleted = false的特殊awaiter，只要await这个对象，一定会触发逻辑切分。
不要滥用Task.Yield实现自定义异步方法：

• 它会平白增加一次调度开销，除非你明确需要强制让出控制权（比如避免长时间占用UI线程），否则完全不需要主动调用
• 它只是把后续逻辑延后执行，解决不了等待自定义事件/IO的需求，不属于异步等待的原生实现方案

控制权释放的底层逻辑 #

你问的同步路径末尾如何释放控制权，核心是awaiter的IsCompleted属性判断：

• async方法执行到await关键字时，会先调用awaiter的IsCompleted属性，如果返回true，说明等待的操作已经完成，会继续同步执行后续逻辑，不会让出控制权
• 如果IsCompleted返回false，运行时会把当前方法剩下的逻辑打包成延续委托，注册到awaiter的OnCompleted方法中，然后直接返回给调用方，控制权就完成了释放，整个过程没有任何线程阻塞。

内容的提问来源于stack exchange，提问作者mmix