async/await 与手工制作的延续： ExecuteSynchronously 是否被巧妙地使用？

我最近写了以下代码：

    Task<T> ExecAsync<T>( string connectionString, SqlCommand cmd, Func<SqlCommand, T> resultBuilder, CancellationToken cancellationToken = default(CancellationToken) )
    {
        var tcs = new TaskCompletionSource<T>();

        SqlConnectionProvider p;
        try
        {
            p = GetProvider( connectionString );
            Task<IDisposable> openTask = p.AcquireConnectionAsync( cmd, cancellationToken );
            openTask
                .ContinueWith( open =>
                {
                    if( open.IsFaulted ) tcs.SetException( open.Exception.InnerExceptions );
                    else if( open.IsCanceled ) tcs.SetCanceled();
                    else
                    {
                        var execTask = cmd.ExecuteNonQueryAsync( cancellationToken );
                        execTask.ContinueWith( exec =>
                        {
                            if( exec.IsFaulted ) tcs.SetException( exec.Exception.InnerExceptions );
                            else if( exec.IsCanceled ) tcs.SetCanceled();
                            else
                            {
                                try
                                {
                                    tcs.SetResult( resultBuilder( cmd ) );
                                }
                                catch( Exception exc ) { tcs.TrySetException( exc ); }
                            }
                        }, TaskContinuationOptions.ExecuteSynchronously );
                    }
                } )
                .ContinueWith( _ =>
                {
                    if( !openTask.IsFaulted ) openTask.Result.Dispose();
                }, TaskContinuationOptions.ExecuteSynchronously );
        }
        catch( Exception ex )
        {
            tcs.SetException( ex );
        }
        return tcs.Task;
    }

这按预期工作。使用 async/await 编写的相同代码（显然）更简单：

async Task<T> ExecAsync<T>( string connectionString, SqlCommand cmd, Func<SqlCommand, T> resultBuilder, CancellationToken cancellationToken = default(CancellationToken) )
{
    SqlConnectionProvider p = GetProvider( connectionString );
    using( IDisposable openTask = await p.AcquireConnectionAsync( cmd, cancellationToken ) )
    {
        await cmd.ExecuteNonQueryAsync( cancellationToken );
        return resultBuilder( cmd );
    }
}

我快速查看了 2 个版本生成的 IL：async/await 更大（并不奇怪），但我想知道 async/await 代码生成器是否分析了延续实际上是同步使用的事实TaskContinuationOptions.ExecuteSynchronously它可以在哪里...但我未能在 IL 生成的代码中找到它。

如果有人知道这一点或有任何线索，我很高兴知道！

我想知道异步/等待代码生成器是否分析了这一事实 延续实际上是同步使用的TaskContinuationOptions.ExecuteSynchronously哪里可以...而我 未能在 IL 生成的代码中找到此内容。

Whether await延续-without ConfigureAwait(continueOnCapturedContext: false)- 异步或同步执行取决于线程上是否存在同步上下文，该线程在执行代码时执行代码await观点。如果SynchronizationContext.Current != null，进一步的行为取决于实施SynchronizationContext.Post.

例如，如果您位于 WPF/WinForms 应用程序的主 UI 线程上，您的延续将在同一线程上执行，但仍然异步地，在消息循环的某些未来迭代中。它将通过发布SynchronizationContext.Post。前提是先行任务已在线程池线程或不同的同步上下文上完成（例如，为什么每个 Dispatcher.BeginInvoke 回调都有唯一的同步上下文？ https://stackoverflow.com/questions/22217477/why-a-unique-synchronization-context-for-each-dispatcher-begininvoke-callback).

如果先行任务已在具有相同同步上下文的线程（例如 WinForm UI 线程）上完成，则await继续将被执行同步地（内联）。SynchronizationContext.Post在这种情况下不会使用。

在没有同步上下文的情况下，await继续将被执行同步地在前面的任务已完成的同一线程上。

这就是它与你的不同之处ContinueWith with TaskContinuationOptions.ExecuteSynchronously实现，它根本不关心初始线程或完成线程的同步上下文，并且总是同步执行延续（有此行为的例外情况 http://blogs.msdn.com/b/pfxteam/archive/2012/02/07/10265067.aspx， 尽管如此）。

您可以使用ConfigureAwait(continueOnCapturedContext: false)更接近所需的行为，但其语义仍然不同于TaskContinuationOptions.ExecuteSynchronously。事实上，它指示调度程序not在具有任何同步上下文的线程上运行延续，因此您可能会遇到以下情况ConfigureAwait(false) 将延续推入线程池 https://stackoverflow.com/questions/22672984/configureawait-pushes-the-continuation-to-a-pool-thread，而您可能一直期望同步执行。

还相关：重访Task.ConfigureAwait(continueOnCapturedContext: false). https://stackoverflow.com/questions/28410046/revisiting-task-configureawaitcontinueoncapturedcontext-false?lq=1