阅读时间太长。 使用 Task.ConfigureAwait(continueOnCapturedContext: false)可能会引入冗余线程切换。我正在寻找一个一致的解决方案。

长版。 ConfigureAwait(false)背后的主要设计目标是减少冗余SynchronizationContext.Post await 的持续回调， 在可能的情况。这通常意味着更少的线程切换和更少的 UI 线程工作。然而，它并不总是如何工作的。

例如，有一个 3rd 方库实现了 SomeAsyncApi应用程序接口(interface)。请注意 ConfigureAwait(false)由于某种原因，在这个库中的任何地方都没有使用:

// some library, SomeClass class
public static async Task<int> SomeAsyncApi()
{
    TaskExt.Log("X1");

    // await Task.Delay(1000) without ConfigureAwait(false);
    // WithCompletionLog only shows the actual Task.Delay completion thread
    // and doesn't change the awaiter behavior

    await Task.Delay(1000).WithCompletionLog(step: "X1.5");

    TaskExt.Log("X2");

    return 42;
}

// logging helpers
public static partial class TaskExt
{
    public static void Log(string step)
    {
        Debug.WriteLine(new { step, thread = Environment.CurrentManagedThreadId });
    }

    public static Task WithCompletionLog(this Task anteTask, string step)
    {
        return anteTask.ContinueWith(
            _ => Log(step),
            CancellationToken.None,
            TaskContinuationOptions.ExecuteSynchronously,
            TaskScheduler.Default);
    }
}

// another library, AnotherClass class
public static async Task MethodAsync()
{
    TaskExt.Log("B1");
    await SomeClass.SomeAsyncApi().ConfigureAwait(false);
    TaskExt.Log("B2");
}

// ... 
// a WinFroms app
private async void Form1_Load(object sender, EventArgs e)
{
    TaskExt.Log("A1");
    await AnotherClass.MethodAsync();
    TaskExt.Log("A2");
}

{ step = A1, thread = 9 }
{ step = B1, thread = 9 }
{ step = X1, thread = 9 }
{ step = X1.5, thread = 11 }
{ step = X2, thread = 9 }
{ step = B2, thread = 11 }
{ step = A2, thread = 9 }

Here, the logical execution flow goes through 4 thread switches. 2 of them are redundant and caused by SomeAsyncApi().ConfigureAwait(false). It happens because ConfigureAwait(false) pushes the continuation to ThreadPool from a thread with synchronization context (in this case, the UI thread).

In this particular case, MethodAsync is better off without ConfigureAwait(false). Then it only takes 2 thread switches vs 4:

{ step = A1, thread = 9 }
{ step = B1, thread = 9 }
{ step = X1, thread = 9 }
{ step = X1.5, thread = 11 }
{ step = X2, thread = 9 }
{ step = B2, thread = 9 }
{ step = A2, thread = 9 }

However, the author of MethodAsync uses ConfigureAwait(false) with all good intentions and following the best practices, and she knows nothing about internal implementation of SomeAsyncApi. It wouldn't be a problem if ConfigureAwait(false) was used "all the way" (i.e., inside SomeAsyncApi too), but that's beyond her control.

That's how it goes with WindowsFormsSynchronizationContext (or DispatcherSynchronizationContext), where we might be not caring about extra thread switches at all. However, a similar situation could happen in ASP.NET, where AspNetSynchronizationContext.Post essentially does this:

Task newTask = _lastScheduledTask.ContinueWith(_ => SafeWrapCallback(action));
_lastScheduledTask = newTask;

await Task.Run(() => SomeAsyncApi()).ConfigureAwait(false);

async Task MethodAsync()
{
    TaskExt.Log("B1");
    await TaskExt.WithNoContext(() => SomeAsyncApi()).ConfigureAwait(false);
    TaskExt.Log("B2");
}

{ step = A1, thread = 8 }
{ step = B1, thread = 8 }
{ step = X1, thread = 8 }
{ step = X1.5, thread = 10 }
{ step = X2, thread = 10 }
{ step = B2, thread = 10 }
{ step = A2, thread = 8 }

public static Task<TResult> WithNoContext<TResult>(Func<Task<TResult>> func)
{
    Task<TResult> task;
    var sc = SynchronizationContext.Current;
    try
    {
        SynchronizationContext.SetSynchronizationContext(null);
        // do not await the task here, so the SC is restored right after
        // the execution point hits the first await inside func
        task = func();
    }
    finally
    {
        SynchronizationContext.SetSynchronizationContext(sc);
    }
    return task;
}

// task = func();
var task2 = new Task<Task<TResult>>(() => func());
task2.RunSynchronously(TaskScheduler.Default); 
task = task2.Unwrap();

I would say that it's the other way around because as Stephen said in his answer "The purpose of ConfigureAwait(false) is not to induce a thread switch (if necessary), but rather to prevent too much code running on a particular special context." which you disagree with and is the root of your compliant.

ConfigureAwait(false) goal is to reduce, as much as possible, the work the "special" (e.g. UI) threads need to process in spite of the thread switches it requires.

Avoid Unnecessary Marshaling

If at all possible, make sure the async implementation you’re calling doesn’t need the blocked thread in order to complete the operation (that way, you can just use normal blocking mechanisms to wait synchronously for the asynchronous work to complete elsewhere). In the case of async/await, this typically means making sure that any awaits inside of the asynchronous implementation you’re calling are using ConfigureAwait(false) on all await points; this will prevent the await from trying to marshal back to the current SynchronizationContext. As a library implementer, it’s a best practice to always use ConfigureAwait(false) on all of your awaits, unless you have a specific reason not to; this is good not only to help avoid these kinds of deadlock problems, but also for performance, as it avoids unnecessary marshaling costs.

最佳答案

当您处理异步操作时，线程切换的开销太小而无需关心(一般来说)。 ConfigureAwait(false)的目的不是为了引发线程切换(如果需要)，而是为了防止在特定的特殊上下文中运行过多的代码。

The reasoning behind this pattern was that "it helps to avoid deadlocks".

关于c# - 重温 Task.ConfigureAwait(continueOnCapturedContext : false)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/28410046/