Assíncrono vs Multithreading - Existe alguma diferença?

Uma chamada assíncrona sempre cria um novo thread? Qual é a diferença entre os dois?

Uma chamada assíncrona sempre cria ou usa um novo thread?

A Wikipedia diz :

Na programação de computadores, eventos assíncronos são aqueles que ocorrem independentemente do fluxo principal do programa. Ações assíncronas são ações executadas em um esquema sem bloqueio, permitindo que o fluxo do programa principal continue processando.

Eu sei que chamadas assíncronas podem ser feitas em threads únicos? Como isso é possível?

Esta questão é quase geral demais para responder.

No caso geral, uma chamada assíncrona não cria necessariamente um novo encadeamento. Essa é uma maneira de implementá-lo, com um pool de encadeamentos preexistentes ou um processo externo sendo outras formas. Depende muito da linguagem, modelo de objeto (se houver) e ambiente de tempo de execução.

Assíncrono significa apenas que o encadeamento de chamada não fica parado e aguarda a resposta, nem a atividade assíncrona acontece no encadeamento de chamada.

Além disso, você precisará ser mais específico.

Sempre que a operação que precisa ocorrer de forma assíncrona não requer que a CPU funcione, essa operação pode ser feita sem gerar outro encadeamento. Por exemplo, se a operação assíncrona for E / S, a CPU não precisará aguardar a conclusão da E / S. Ele só precisa iniciar a operação e pode prosseguir para outro trabalho enquanto o hardware de E / S (controlador de disco, interface de rede etc.) faz o trabalho de E / S. O hardware avisa a CPU quando terminar, interrompendo a CPU, e o sistema operacional entrega o evento ao seu aplicativo.

As abstrações e APIs de nível superior frequentemente não expõem as APIs assíncronas subjacentes disponíveis no SO e no hardware subjacente. Nesses casos, geralmente é mais fácil criar threads para executar operações assíncronas, mesmo se o thread gerado estiver apenas aguardando uma operação de E / S.

Se a operação assíncrona exigir que a CPU funcione, geralmente essa operação deve ocorrer em outro encadeamento para que seja verdadeiramente assíncrona. Mesmo assim, será realmente assíncrono apenas se houver mais de uma unidade de execução.

Não, chamadas assíncronas nem sempre envolvem threads.

Eles normalmente iniciam algum tipo de operação que continua em paralelo com o chamador. Mas essa operação pode ser gerenciada por outro processo, pelo sistema operacional, por outro hardware (como um controlador de disco), por algum outro computador na rede ou por um ser humano. Threads não são a única maneira de fazer as coisas em paralelo.

O JavaScript é de thread único e assíncrono. Ao usar o XmlHttpRequest, por exemplo, você fornece uma função de retorno de chamada que será executada de forma assíncrona quando a resposta retornar.

John Resig tem uma boa explicação sobre a questão relacionada de como os temporizadores funcionam em JavaScript .

O multiencadeamento refere-se a mais de uma operação acontecendo no mesmo processo. Enquanto a programação assíncrona se espalha pelos processos. Por exemplo, se minhas operações chamam um serviço da web, o encadeamento não precisa esperar até o serviço da web retornar. Aqui usamos a programação assíncrona que permite que o thread não espere que um processo em outra máquina seja concluído. E quando começa a receber resposta do serviço da web, ele pode interromper o thread principal para dizer que o serviço da web concluiu o processamento da solicitação. Agora o thread principal pode processar o resultado.

O Windows sempre teve processamento assíncrono desde os tempos não preventivos (versões 2.13, 3.0, 3.1, etc.) usando o loop de mensagens, muito antes de oferecer suporte a threads reais. Portanto, para responder sua pergunta, não, não é necessário criar um encadeamento para executar o processamento assíncrono.

Chamadas assíncronas nem precisam ocorrer no mesmo sistema / dispositivo que o que está chamando. Portanto, se a pergunta for: uma chamada assíncrona exige um encadeamento no processo atual, a resposta é não. No entanto, deve haver um encadeamento de execução em algum lugar processando a solicitação assíncrona.

Thread de execução é um termo vago. Em sistemas de tarefas cooperativas, como os primeiros sistemas operacionais Macintosh e Windows, o encadeamento de execução pode ser simplesmente o mesmo processo que fez a solicitação executar outra pilha, ponteiro de instruções, etc ... No entanto, quando as pessoas geralmente falam sobre chamadas assíncronas , eles geralmente significam chamadas que são tratadas por outro encadeamento, se for intraprocesso (ou seja, dentro do mesmo processo) ou por outro processo, se for interprocesso.

Observe que a comunicação entre processos (ou interprocessos) (IPC) é geralmente generalizada para incluir comunicação entre processos, já que as técnicas de bloqueio e sincronização de dados geralmente são as mesmas, independentemente do processo em que os threads de execução separados são executados.

Alguns sistemas permitem que você aproveite a concorrência no kernel para alguns recursos usando retornos de chamada. Para uma instância bastante obscura, os retornos de chamada de entrada / saída assíncrona foram usados ​​para implementar servidores de Internet sem bloqueio nos dias de multitarefa sem preempção do Mac System 6-8.

Dessa forma, você tem fluxos de execução simultâneos "no" que programa sem threads, como tal .

Assíncrono significa apenas que você não bloqueia seu programa esperando que algo (chamada de função, dispositivo etc.) termine. Ele pode ser implementado em um encadeamento separado, mas também é comum usar um encadeamento dedicado para tarefas síncronas e se comunicar por meio de algum tipo de sistema de eventos e, assim, obter um comportamento assíncrono.

Existem exemplos de programas assíncronos de thread único. Algo como:

...do something
...send some async request
while (not done)
    ...do something else
    ...do async check for results

A natureza das chamadas assíncronas é tal que, se você deseja que o aplicativo continue em execução enquanto a chamada está em andamento, será necessário gerar um novo encadeamento ou, pelo menos, utilizar outro encadeamento que você criou exclusivamente para os propósitos de manipulação de retornos de chamada assíncronos.

Às vezes, dependendo da situação, convém chamar um método assíncrono, mas fazer com que o usuário pareça síncrono (ou seja, bloqueie até que o método assíncrono sinalize que está completo). Isso pode ser alcançado por meio de APIs do Win32, como WaitForSingleObject .