Asincrono vs Multithreading - C'è una differenza?

Question

Una chiamata asincrona crea sempre un nuovo thread? Qual è la differenza tra i due?

Una chiamata asincrona crea sempre o utilizza un nuovo thread?

Wikipedia says:

Nella programmazione di computer, eventi asincroni sono quelle che si verificano indipendentemente dal flusso del programma principale. Le azioni asincrone sono azioni eseguite in uno schema non bloccante, consentendo al flusso del programma principale di continuare l'elaborazione.

So che le chiamate asincrone possono essere eseguite su thread singoli? Com'è possibile?

Answer 1

Questa domanda è davvero troppo generica per rispondere.

Nel caso generale, una chiamata asincrona non crea necessariamente un nuovo thread. Questo è un modo per implementarlo, con un pool di thread preesistente o un processo esterno che sono altri modi. Dipende molto dalla lingua, dal modello oggetto (se esiste) e dall'ambiente di esecuzione.

Asincrono significa semplicemente che il thread chiamante non si siede e attende la risposta, né l'attività asincrona si verifica nel thread chiamante.

Oltre a ciò, è necessario ottenere informazioni più specifiche.

Answer 2

Windows ha sempre elaborato in modo asincrono i tempi non preventivi (versioni 2.13, 3.0, 3.1, ecc.) Utilizzando il ciclo dei messaggi, prima di supportare i thread reali. Quindi, per rispondere alla tua domanda, no, non è necessario creare un thread per eseguire l'elaborazione asincrona.

Answer 3

Asincrono significa semplicemente che non si blocca il programma in attesa di qualcosa (chiamata di funzione, dispositivo, ecc.) Per terminare. Può essere implementato in un thread separato, ma è anche comune utilizzare un thread dedicato per attività sincrone e comunicare tramite un qualche tipo di sistema di eventi e ottenere così un comportamento asincrono.

Esistono esempi di programmi asincroni a thread singolo. Qualcosa di simile:

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

Answer 4

Alcuni sistemi consentono di sfruttare la concorrenza nel kernel per alcune strutture che utilizzano i callback. Per un'istanza alquanto oscura, sono stati utilizzati richiami di I/O asincroni per implementare i sever di Internet non bloccanti nei giorni multitasking senza preclusioni di Mac System 6-8.

In questo modo si hanno flussi di esecuzione simultanei "in" programmi senza fili come tali.

Answer 5

La natura delle chiamate asincrone è tale che, se si desidera che l'applicazione continui a funzionare mentre la chiamata è in corso, vi sia bisogno di uova un nuovo thread, o almeno utilizzare un altro thread che hai creato esclusivamente per la gestione di callback asincroni.

A volte, a seconda della situazione, è possibile che si desideri richiamare un metodo asincrono ma fare in modo che all'utente venga visualizzato il carattere sincrono (ovvero blocco finché il metodo asincrono non ha segnalato che è completo). Questo può essere ottenuto tramite API Win32 come WaitForSingleObject.

Answer 6

Le chiamate asincrone non devono nemmeno verificarsi sullo stesso sistema/dispositivo di quello che ha richiamato la chiamata. Quindi se la domanda è, una chiamata asincrona richiede un thread nel processo corrente, la risposta è no. Tuttavia, deve esistere un thread di esecuzione da qualche parte per l'elaborazione della richiesta asincrona.

Il thread di esecuzione è un termine vago. In un sistema collaborativo come i primi sistemi operativi Macintosh e Windows, il thread di esecuzione potrebbe essere semplicemente lo stesso processo che ha fatto in modo che la richiesta eseguisse un altro stack, puntatore di istruzioni, ecc ... Tuttavia, quando le persone parlano generalmente di chiamate asincrone , in genere indicano chiamate gestite da un altro thread se è intra-processo (cioè all'interno dello stesso processo) o da un altro processo se è inter-processo.

Nota che la comunicazione tra processi (o interprocesso) (IPC) è comunemente generalizzata per includere la comunicazione intra-processo, poiché le tecniche per il blocco e la sincronizzazione dei dati sono solitamente le stesse indipendentemente da quale processo i thread separati di esecuzione run in.

Answer 7

Ogni volta che l'operazione che deve avvenire in modo asincrono non richiede che la CPU lavori, tale operazione può essere eseguita senza generare altro thread. Ad esempio, se l'operazione asincrona è I/O, la CPU non deve attendere il completamento dell'I/O. Ha solo bisogno di iniziare l'operazione, e può quindi passare ad altri lavori mentre l'I/O hardware (controller del disco, interfaccia di rete, ecc.) Esegue l'I/O. L'hardware consente alla CPU di sapere quando ha finito interrompendo la CPU e il sistema operativo invia l'evento alla tua applicazione.

Spesso le astrazioni e le API di livello superiore non espongono le API asincrone sottostanti disponibili dal sistema operativo e dall'hardware sottostante. In questi casi, in genere è più semplice creare thread per eseguire operazioni asincrone, anche se il thread generato è in attesa di un'operazione di I/O.

Se l'operazione asincrona richiede che la CPU lavori, in genere tale operazione deve avvenire in un altro thread affinché sia ​​veramente asincrona. Anche allora, sarà davvero solo asincrono se c'è più di una unità di esecuzione.

Answer 8

JavaScript è single-threaded e asincrono. Quando si utilizza XmlHttpRequest, ad esempio, si fornisce una funzione di callback che verrà eseguita in modo asincrono al termine della risposta.

John Resig ha una buona spiegazione del problema correlato di come timers work in JavaScript.

Answer 9

No, le chiamate asincrone non implicano sempre thread.

In genere avviano una sorta di operazione che continua in parallelo con il chiamante. Ma quell'operazione potrebbe essere gestita da un altro processo, dal sistema operativo, da altro hardware (come un controller del disco), da qualche altro computer sulla rete o da un essere umano. I thread non sono l'unico modo per fare le cose in parallelo.

Answer 10

Il threading multiplo si riferisce a più operazioni che si verificano nello stesso processo. Mentre la programmazione asincrona si diffonde attraverso i processi. Ad esempio, se le mie operazioni richiedono un servizio web, il thread non deve attendere fino al ritorno del servizio web. Qui usiamo la programmazione asincrona che consente al thread di non attendere il completamento di un processo in un'altra macchina. E quando inizia a ricevere una risposta dal webservice, può interrompere il thread principale per dire che il servizio web ha completato l'elaborazione della richiesta. Ora il thread principale può elaborare il risultato.