Código assíncrono, variáveis ​​compartilhadas, threads do pool de threads e segurança de threads

Quando escrevo código assíncrono com async / waitit, geralmente com ConfigureAwait(false)para evitar capturar o contexto, meu código está saltando de um segmento de pool de threads para o próximo após cada um await. Isso levanta preocupações sobre a segurança do encadeamento. Esse código é seguro?

static async Task Main()
{
    int count = 0;
    for (int i = 0; i < 1_000_000; i++)
    {
        Interlocked.Increment(ref count);
        await Task.Yield();
    }
    Console.WriteLine(count == 1_000_000 ? "OK" : "Error");
}

A variável não iestá protegida e é acessada por vários threads * do conjunto de encadeamentos. Embora o padrão de acesso seja não simultâneo, teoricamente deve ser possível para cada encadeamento incrementar um valor armazenado em cache localmente i, resultando em mais de 1.000.000 de iterações. Eu sou incapaz de produzir esse cenário na prática. O código acima sempre imprime OK na minha máquina. Isso significa que o código é seguro para threads? Ou devo sincronizar o acesso à ivariável usando um lock?

(* uma opção de thread ocorre a cada 2 iterações, em média, de acordo com meus testes)

O problema com a segurança de threads é sobre a leitura / gravação de memória. Mesmo quando isso pode continuar em um thread diferente, nada aqui é executado simultaneamente.

Acredito que este artigo de Stephen Toub possa esclarecer isso. Em particular, esta é uma passagem relevante sobre o que acontece durante uma troca de contexto:

Sempre que o código aguarda um aguardável cujo garçom diz que ainda não está completo (ou seja, o IsCompleted do garçom retorna falso), o método precisa ser suspenso e será retomado por uma continuação fora do garçom. Esse é um desses pontos assíncronos aos quais me referi anteriormente e, portanto, o ExecutionContext precisa fluir do código que emite a espera até a execução do delegado de continuação. Isso é tratado automaticamente pelo Framework. Quando o método assíncrono está prestes a suspender, a infraestrutura captura um ExecutionContext. O delegado que é passado para o garçom tem uma referência a esta instância ExecutionContext e a utilizará ao retomar o método. É isso que permite que as importantes informações "ambientais" representadas pelo ExecutionContext fluam entre aguardas.

Vale ressaltar que os YieldAwaitableretornados Task.Yield()sempre retornam false.