async + aguardar == sincronizar?

Tropecei neste post que fala sobre fazer solicitações da Web assíncronas.

Agora, a simplicidade à parte, se no mundo real, tudo o que você faz é fazer uma solicitação assíncrona e aguardá-la na próxima linha, não é o mesmo que fazer uma chamada de sincronização em primeiro lugar?

Não, async + await != syncpor causa da continuação

Do MSDN 'Programação assíncrona com Async e Await (C # e Visual Basic)'

Os métodos assíncronos devem ser operações sem bloqueio. Uma expressão de espera em um método assíncrono não bloqueia o encadeamento atual enquanto a tarefa aguardada está em execução. Em vez disso, a expressão inscreve o restante do método como uma continuação e retorna o controle para o chamador do método assíncrono .

Por exemplo, a execução assíncrona não bloqueará o thread da interface do usuário e Some TextBox.Textserá atualizada após a conclusão do download

private async void OnButtonClick()
{
   SomeTextBox.Text = await new WebClient().DownloadStringTaskAsync("http://stackoverflow.com/");
}

Não, não é o mesmo.

Seu asyncbloco de código está aguardando o awaitretorno da chamada para continuar, no entanto, o restante do seu aplicativo não está esperando e ainda pode continuar normalmente.

Por outro lado, uma chamada síncrona faria todo o aplicativo ou thread aguardar até que o código terminasse a execução para continuar com qualquer outra coisa.

Por favor, permita-me esclarecer as coisas em relação ao assíncrono / aguardar.

Quando aguardar, a máquina de estado subjacente permite que o controle seja retornado imediatamente. Então, quando a chamada esperada for concluída, a máquina de estado subjacente permitirá que a execução continue na linha após a chamada aguardada.

Portanto, o bloco assíncrono não está bloqueado nem está aguardando o término da chamada esperada; O controle é retornado imediatamente quando o comando de espera é encontrado.

A máquina de estado subjacente faz parte da "mágica" por trás do uso de async / wait que não é desutilizada e perdida.

Eu tropecei nisso com a mesma pergunta em mente, mas depois de ler as respostas, a pergunta parece persistir, confusa com as referências à "mágica escondida".

Na programação assíncrona mencionada acima :

• A asyncpalavra-chave transforma um método em um método assíncrono, que permite usar a awaitpalavra - chave em seu corpo.
• Quando a awaitpalavra-chave é aplicada, ela suspende o método de chamada e retorna o controle ao chamador até que a tarefa esperada seja concluída.
• awaitsó pode ser usado dentro de um asyncmétodo.

O contexto encontrado encontra- awaitse bloqueado?

• Sim . Essa é essencialmente uma barreira de sincronização local para manter um estado conhecido no contexto da execução; exceto que outros contextos, se houver, não são unidos.

O restante do aplicativo bloqueia no await?

• Depende de como seu aplicativo foi gravado. Se houver uma série de awaittarefas ed dependentes iniciadas sequencialmente no mesmo contexto (consulte: Tentando entender algum comportamento assíncrono / aguardar )

  await asyncCall1();
  await asyncCall2();  // waits for asyncCall1() to complete

  Dessa maneira, cada um awaitdeles bloquearia a desova do próximo.

  Por outro lado, as mesmas tarefas dependentes lançadas em paralelo seriam executadas em paralelo e o contexto seria bloqueado apenas nas respectivas. await:

  Task<int> t1 = asyncCall1();
  Task<string> t2 = asyncCall2();  // runs in parallel with asyncCall1()
  int val = await t1;
  string str = await t2;  // waits for asyncCall1() to complete

  Em geral, a awaitexecução gera o contexto externo, de onde o contexto atual é chamado. No entanto, se o contexto externo em si está aguardando a corrente, é como um awaits seqüencial no mesmo contexto.

Portanto, para colher os asyncbenefícios, é necessário projetar o aplicativo para executar vários contextos paralelos (interface do usuário, cliente de dados etc.) e, awaitem um contexto, gerar execução para outros contextos, para que o aplicativo inteiro não bloqueie um indivíduo await.