![]() |
Criado por Thiago Russo
aproximadamente 7 anos atrás
|
|
Questão | Responda |
PQ é importante conhecer operações dE I/O assíncronas? | Ao trabalhar com I/O, mtas vezes vc tem que esperar uma operação terminar. Talvez você tenha que esperar antes que um arquivo seja lido a partir do disco rígido ou antes de uma solicitação de rede retornar de algum lugar no mundo. Todo o código que você já viu até agora neste capítulo é chamado de código síncrono. O código é executado linha por linha e espera até que cada método termine. Uma linha aparentemente inocente de código de repente pode gastar muito tempo enquanto você está esperando que ela termine. Isso pode ter um grave impacto sobre a experiência do usuário e a escalabilidade do seu aplicativo. |
Operações longas em aplicações Desktop | Qdo vc cria um aplicativo de desktop, como Windows Presentation Foundation (WPF), WinForm, ou aplicativo do Windows Store, a sua aplicação tem uma thread principal que é responsável por atualizar a interface do usuário. Esta thread é responsável pelo processamento de todas as atividades do usuário. Se esta thread está ocupada com outra coisa, o aplicativo parece ficar sem resposta. A maioria dos usuários, em seguida, tentar fechar a aplicação, porque eles pensam que algo está errado. É importante executar operações de longa execução em outra thread, o que garante que sua aplicação permaneça respondendo enquanto está executando a operação de longa execução em segundo plano (background). |
Operações longas em aplicações Web | Com um aplicativo de servidor, as coisas são um pouco diferentes. Qdo o usuário acessa o servidor de web ASP.NET, ele tem que esperar até q a solicitação seja concluída. Se a página demora muito tempo para carregar, o usuário percebe isso como um mau desempenho. O que está acontecendo no servidor é que uma thread está pegando o pedido e começa a criar a resposta para o usuário. O servidor inicia a coleta de dados, produzindo HTML, e realiza todos os tipos de outras ações. Um servidor tem uma qtde limitada de threads para lidar com solicitações de entrada. Qdo uma thread está aguardando I/O acontecer, ele não pode trabalha em quaisquer outras requisições. Qdo as threads estão ocupadas, e uma nova solicitação chega, a nova solicitação entra na fila. Esse problema é chamado de "thread pool starvation" ("pool de threads com fome"). Todas as threads estão aguardando para alguns I /O acontecer com uma carga de CPU de 0%, e os tempos de resposta para as novas requisições vão ao céu. |
código que trabaha de forma assíncrona resolve esse problema | Este é o lugar onde as operações assíncronas podem ser úteis. Quando seu aplicativo aguarda alguma resposta externa que não é vinculado à CPU, você pode fazer o seu código trabalhar de forma assíncrona para permanecer ágil e para liberar o thread principal para outras solicitações. Código assíncrono já era possível antes do C# 5. Você pode usar o padrão de programação assíncrona baseada em evento (Event-based Asynchronous Programming) para conectar o código para continuar o processamento quando uma requisição externo termina. Entretanto, escrever código assíncrono completamente à mão e recebendo todos os pequenos detalhes direito é difícil, especialmente quando você precisa de manipulação de exceção. Não é tarefa trivial para se certificar de que seu código manipula bem todas as situações. |
I/O x async/await | C# 5 apresenta as novas palavras-chave async / await, que sinalizam para o compilador que você deseja executar algum código assíncrono. O compilador então é responsável por transformar o seu código "aparentemente síncrono" em uma máquina de estado que lida com todas as situações possíveis. I/ O é uma área do .NET Framework que se beneficia muito do novo suporte para async / await. Quando você olha os métodos de E / S neste capítulo, você vai ver muitos métodos têm um equivalente assíncrono que retorna Task ou Task<T>. |
Exemplo de como escrever arquivo de forma assíncrona de verdade! |
Image:
Async Await (image/png)
|
Exemplo de operação assíncrona com retorno Task<string> | |
é bom usar as operações assíncronas que o .Net oferece? | Sempre que o .NET Framework oferecer um equivalente assíncrona de um método síncrono, é melhor usá-lo. Ele cria uma melhor experiência de usuário e uma aplicação mais escalável. Contudo, quando você está trabalhando em um aplicativo de desempenho crítico, vale a pena saber o que o compilador faz por você. Se não tiver certeza, use um profiler para realmente medir a diferença para que você possa tomar uma decisão informada. |
exemplo executando operações de I / O em paralelo "múltiplos awaits" | |
múltiplos request em parelelo | |
dica de quando usar async/await | Usando Tasks e async/await faz a utilização de código assíncrono ser muito mais fácil. Sempre que possível, determine se uma operação vai demorar muito tempo e não é vinculado à CPU. Se verdadeiro ou provável que seja verdade, executar de forma assíncrona é uma boa ideia. |
Quer criar seus próprios Flashcards gratuitos com GoConqr? Saiba mais.