Operazione asincrona e thread in C#

Question

La programmazione asincrona è una tecnica che chiama in background un metodo a esecuzione prolungata in modo che il thread dell'interfaccia utente rimanga reattivo. Dovrebbe essere utilizzato durante la chiamata a un servizio Web oa una query del database oa qualsiasi operazione associata all'I/O. quando il metodo asincrono viene completato, restituisce il risultato nel thread principale. In questo modo, il thread principale del programma non deve attendere il risultato di un'operazione I/O associata e continua ad eseguire ulteriormente senza bloccare/congelare l'interfaccia utente. Questo va bene.

Per quanto ne so, il metodo asincrono viene eseguito su un thread di background worker. Il runtime rende disponibile il thread dal threadpool o può creare un thread nuovo di zecca per la sua esecuzione.

Ma in molti post ho letto che un'operazione asincrona può essere eseguita su un thread separato o senza utilizzare alcun thread. Ora sono molto confuso.

1) Potrebbe aiutarci a chiarire in quale situazione un'operazione asincrona non utilizzerà un thread?

2) Qual è il ruolo del core del processore in funzionamento asincrono?

3) Come è diverso dal multithreading? Conosco una cosa su cui il multithreading è utile con un'operazione legata all'elaborazione.

Per favore aiuto.

Answer 1

IO (diciamo un database-operazione attraverso la rete) è un buon esempio per tutti e tre:

1. è fondamentalmente solo registrare un callback il sistema operativo potrà finalmente chiamare (forse su un poi di recente creato thread) al termine dell'operazione IO. Non v'è alcun filo seduti attorno e in attesa - la risurrezione sarà attivato da hardware-eventi (o almeno da un processo del sistema operativo di solito al di fuori dello spazio utente)

2. potrebbe avere nessuno (vedi 1)

3. in Multithreading usi più di un thread (il tuo thread di background) e lì puoi restare inattivo senza fare nulla (ma usando le risorse di sistema) - questo è ovviamente diverso se tu hai qualcosa da calcolare (quindi il thread è non inattivo in attesa di risultati esterni) - ha senso utilizzare un thread di background-worker

Answer 2

Le operazioni asincrone in realtà non implicano gran parte del modo in cui vengono elaborate, ma solo che a loro piacerebbe l'opzione di tornare più tardi con i risultati. A titolo di esempio:

• Possono (come già menzionato) suddividere un'attività legata a calcolo su un thread indipendente, ma questo non è l'unico caso di utilizzo.
• A volte possono essere completati in modo sincrono all'interno della chiamata che li avvia, nel qual caso non viene utilizzato alcun thread aggiuntivo. Ciò può accadere con una richiesta I/O se c'è già abbastanza contenuto del buffer (input) o spazio buffer libero (output) per soddisfare la richiesta.
• Possono semplicemente abbandonare una richiesta I/O di lunga durata nel sistema; in questo caso è probabile che il callback si verifichi su un thread in background dopo aver ricevuto la notifica da una porta di completamento I/O.
• Al termine, una richiamata può essere consegnata successivamente sullo stesso thread; questo è particolarmente comune con gli eventi all'interno di un framework UI, come la navigazione in un WebBrowser.

Answer 3

Asincronismo non dice nulla sul thread. Si tratta di avere una sorta di richiami che verranno gestiti all'interno di una "statemachine" (non proprio corretta ma si può pensare ad essa come eventi). Asynchronity non genera thread né alloca significativamente risorse di sistema. È possibile eseguire tutti i metodi asincroni che si desidera.

I thread hanno un reale impatto sul sistema e si dispone di un numero enorme ma limitato che è possibile avere in una volta.

Le operazioni Io sono principalmente correlate ad altri controller (HDD, NIC, ...) Ciò che ora accade se si crea un thread è che un thread dell'applicazione che non ha nulla da fare attende che i controller finiscano. In modo asincrono come già menzionato da Carsten e Jeffrey, si ottiene una sorta di meccanismo di callback in modo che il thread continui a svolgere altri lavori, metodi e così via.

Anche tenere a mente che ogni thread costa le risorse (RAM, performance, maniglie Garbage Collection è peggiorata, ...) e può anche e in eccezioni (OutOfMemoryException ...)

Così, quando a utilizzare i thread ? Assolutamente solo se ne hai davvero bisogno. Se c'è una API asincrona usala a meno che tu non abbia dei motivi davvero importanti per non usarla. Nei giorni scorsi l'api asincrone era davvero dolorosa, ecco perché molte persone usavano i thread quando mai avevano bisogno solo di asincronismo.

Ad esempio node.js rifiuta assolutamente l'uso del thread multeo!

Questo è particolarmente importante se si gestiscono più richieste, ad esempio in servizi/siti Web in cui c'è sempre lavoro da fare. C'è anche un questo breve webcast with Jeffrey Richter su questo che mi ha aiutato a capire

hanno anche uno sguardo a questo MSDN article PS: Come sorgente effetto collaterale con async e attendono tendono ad essere più leggibile