Trago pra vocês um trecho do texto do Fernando Ferreira que explica bastante sobre programação assíncrona:
"De uma forma natural, os códigos que escrevemos no dia a dia são chamados puramente operações síncronas, essas operações têm como thread de execução a própria thread que realizou a chamada. No momento em que executamos alguma operação síncrona, essa operação inicia a sua execução, bloqueando a thread atual para as demais operações até que ela termine de executar e passe o controle novamente para a thread principal, que se encarregará de prosseguir com as demais operações que aguardam.
O grande problema dessa situação é que se a operação a ser executada demorar muito tempo para realizar o processamento, isso acarretará em demasiada espera para as demais operações. Trabalhar dessa forma é subutilizar o hardware, claro que nem todas as operações têm a necessidade de serem assíncronas, mas temos que ser cuidadosos na hora de definir qual operação será ou não síncrona.
Por outro lado, o .NET Framework nos permite o desenvolvimento com operações assíncronas, as operações assíncronas não possuem um desenvolvimento tão natural assim como as operações síncronas, elas demandam um certo conhecimento por parte do desenvolvedor, exigem mais tempo para serem desenvolvidas e eis um dos motivos pelo qual a maioria dos sistemas ainda não contemplam essas técnicas em seu código. Esse tipo de operação funciona de forma a não bloquear a thread principal do sistema garantindo um fluxo contínuo nas operações.
No momento em que é executada uma operação assíncrona, é criada outra thread para essa operação e o controle volta para a thread principal que prossegue com a execução das demais operações, ou seja, agora temos duas threads rodando em paralelo, uma para o método custoso e a outra com as operações que são mais rápidas e/ou que não precisam aguardar o término da primeira operação garantindo fluidez ao sistema."
"De uma forma natural, os códigos que escrevemos no dia a dia são chamados puramente operações síncronas, essas operações têm como thread de execução a própria thread que realizou a chamada. No momento em que executamos alguma operação síncrona, essa operação inicia a sua execução, bloqueando a thread atual para as demais operações até que ela termine de executar e passe o controle novamente para a thread principal, que se encarregará de prosseguir com as demais operações que aguardam.
O grande problema dessa situação é que se a operação a ser executada demorar muito tempo para realizar o processamento, isso acarretará em demasiada espera para as demais operações. Trabalhar dessa forma é subutilizar o hardware, claro que nem todas as operações têm a necessidade de serem assíncronas, mas temos que ser cuidadosos na hora de definir qual operação será ou não síncrona.
Por outro lado, o .NET Framework nos permite o desenvolvimento com operações assíncronas, as operações assíncronas não possuem um desenvolvimento tão natural assim como as operações síncronas, elas demandam um certo conhecimento por parte do desenvolvedor, exigem mais tempo para serem desenvolvidas e eis um dos motivos pelo qual a maioria dos sistemas ainda não contemplam essas técnicas em seu código. Esse tipo de operação funciona de forma a não bloquear a thread principal do sistema garantindo um fluxo contínuo nas operações.
No momento em que é executada uma operação assíncrona, é criada outra thread para essa operação e o controle volta para a thread principal que prossegue com a execução das demais operações, ou seja, agora temos duas threads rodando em paralelo, uma para o método custoso e a outra com as operações que são mais rápidas e/ou que não precisam aguardar o término da primeira operação garantindo fluidez ao sistema."