您可以在没有线程安全的情况下使用 ConfigureAwait(false) 吗？

Question

我看到各地的人都建议尽可能使用ConfigureAwait(false)，这是图书馆作者必须使用的，等等。

但是由于ConfigureAwait(false) 的延续可以在线程池中的任何线程上运行，那么如何安全地防止多个线程访问库中的相同状态？

假设您的库有以下 API：

async Task FooAsync()
{
    // Do something
    
    //barAsync and saveToFileAsync are private methods.
    await barAsync().ConfigureAwait(false);
    
    // counter is a private field
    counter++;

    await saveToFileAsync().ConfigureAwait(false);
    
    // Do other things
}

如果 UI 线程一直调用此 FooAsync（例如，由于用户按下按钮），此代码不会损坏 counter 的值并保存文件吗？由于可能正在执行多个线程？

除了不修改状态的最简单的情况外，我发现很难在没有线程安全的情况下使用 ConfigureAwait(false)。

更新

我可能不清楚，但在我们的团队中，我们决定使用单线程。因此，从下面的答案来看，我们似乎不能使用ConfigureAwait(false)，因为它引入了并行的可能性，需要使用锁等来控制。

Answer 1

但由于 ConfigureAwait(false) 的延续可以在线程池中的任何线程上运行，那么如何安全地防止多个线程访问库中的相同状态？

await 确实引入了重入的可能性，但它实际上导致问题的情况很少见。异步代码本质上鼓励一种功能性更强的结构（方法的输入是它的参数，输出是它的返回值）。 可能异步方法有副作用并依赖于状态，但这并不常见。

请注意，导致意外重入的是await。 ConfigureAwait(false) 在线程池中恢复，但这不会导致这里出现问题。

如果 UI 线程不断调用此 FooAsync（例如，由于用户按下按钮），此代码不会损坏计数器的值并保存文件吗？由于可能正在执行多个线程？

是的，有点像。是的，计数器可能会得到一个意外的值，但这不一定是因为多个线程。考虑没有ConfigureAwait(false) 的相同代码：您仍然可以在单个线程上运行该函数的多个调用。他们仍在为柜台和任何其他共享状态而战。在这种情况下，由于是单线程，counter++ 是原子的，但由于它是共享的，因此从 await 恢复时，对该函数的单次调用可能会看到值意外更改。

使用ConfigureAwait(false)，你确实有额外的担心并行（使用await你有意外重入），所以如果你有非线程安全的共享状态，事情会变得更糟。重入会导致意外状态，但并行性会导致无效状态。

Answer 2

ConfigureAwait 与线程安全无关。这是关于避免捕获上下文。

如果您希望您的代码是线程安全的，那么您应该实现它。这通常涉及使用某种同步结构，例如锁。

正如已经指出的那样，即使您删除了对 ConfigureAwait(false) 的调用，您的 FooAsync() 也不是线程安全的。即使在有SynchronizationContext 可用的UI 应用程序中，两个或多个线程仍然可以同时调用它。

如何安全地防止多个线程访问库中的同一状态？

通过同步对任何共享资源的访问。假设counter 是您代码中唯一的关键部分，您可以使用Interlocked.Increment API 使方法线程安全：

async Task FooAsync()
{
    ...
    Interlocked.Increment(ref counter);
    ...
}

这将增加counter 并将新结果存储为原子操作。

还有很多其他的同步结构。使用哪一个取决于您基本上在做什么。避免调用ConfigureAwait(false) 不是让代码线程安全的方法。