Le coroutine sono ciò che in Informatica chiamiamo "multitasking cooperativo". Sono un modo per più flussi diversi di esecuzione interagire tra loro in modo cooperativo. Nel multitasking cooperativo un flusso di esecuzione ha la sola proprietà indiscussa della CPU fino a quando non raggiunge un yield. A quel punto, Unity (o qualunque framework tu stia usando), ha la possibilità di passare a un diverso flusso di esecuzione. Quindi ottiene anche la sola proprietà indiscussa della CPU fino a quando non lo yieldè.
Le discussioni sono ciò che chiamiamo "multitasking preventivo". Quando si utilizzano i thread, il framework si riserva il diritto in qualsiasi momento di interrompere la discussione a metà e passare a un altro thread. Non importa dove ti trovi. In alcuni casi puoi persino essere interrotto durante la scrittura di una variabile in memoria!
Ci sono pro e contro per ciascuno. I contro delle coroutine sono probabilmente i più facili da capire. Prima di tutto, le coroutine vengono eseguite su un singolo core. Se si dispone di una CPU quad core, le coroutine utilizzeranno solo uno dei quattro core. Questo semplifica le cose, ma in alcuni casi può essere un problema di prestazioni. Il secondo svantaggio è che devi essere consapevole del fatto che qualsiasi procedura di coroutine può fermare l'intero programma semplicemente rifiutando di farlo yield. Questo è stato un problema su Mac OS9, molti anni fa. OS9 supportava solo il multitasking cooperativo, nell'intero computer. Se uno dei tuoi programmi si bloccasse, potrebbe arrestare il computer in modo così violento che il sistema operativo non potrebbe nemmeno visualizzare il testo del messaggio di errore per farti sapere cosa è successo!
I pro delle coroutine sono che sono relativamente facili da capire. Gli errori che hai sono molto più prevedibili. In genere richiedono anche meno risorse, il che può essere utile mentre sali nelle decine di migliaia di coroutine o fili. Candid Moon ha menzionato nei commenti che, se non hai studiato correttamente le discussioni, resta fedele alle coroutine e hanno ragione. Le coroutine sono molto più semplici con cui lavorare.
Le discussioni sono completamente una bestia diversa. Devi sempre stare in guardia contro la possibilità che un altro thread possa interromperti in qualsiasi momentoe pasticciare con i tuoi dati. Le librerie di threading forniscono intere suite di potenti strumenti per aiutarti in questo, come mutex e variabili di condizione che ti aiutano a dire al sistema operativo quando è sicuro che esegua uno degli altri thread e quando non è sicuro. Ci sono interi corsi dedicati a come usare bene questi strumenti. Uno dei problemi famosi che si presentano è un "deadlock", ovvero quando due thread si "bloccano" entrambi aspettando che l'altro liberi alcune risorse. Un altro problema, che è molto importante per Unity, è che molte librerie (come Unity) non sono progettate per supportare chiamate da più thread. È possibile interrompere facilmente il framework se non si presta attenzione a quali chiamate sono consentite e quali sono vietate.
Il motivo di questa ulteriore complessità è in realtà molto semplice. Il modello di multitasking preventivo è davvero simile al modello di multithreading che consente non solo di interrompere altri thread, ma di eseguire effettivamente thread affiancati su core diversi. Questo è incredibilmente potente, essendo l'unico modo per sfruttare davvero queste nuove CPU quad core ed esadecimali che stanno uscendo, ma apre la finestra di Pandora. Le regole di sincronizzazione su come gestire questi dati in un mondo multithreading sono decisamente brutali. Nel mondo C ++, ci sono interi articoli dedicati ai MEMORY_ORDER_CONSUMEquali è un angolo di sincronizzazione multithreading.
Quindi i contro del threading? Semplice: sono difficili. Puoi imbatterti in intere classi di bug che non hai mai visto prima. Molti sono i cosiddetti "heisenbugs" che a volte compaiono e poi scompaiono quando li esegui il debug. Gli strumenti che ti vengono dati per gestirli sono molto potenti, ma sono anche di livello molto basso. Sono progettati per essere efficienti sulle architetture dei chip moderni anziché essere progettati per essere facili da usare.
Tuttavia, se si desidera utilizzare tutta la potenza della CPU, sono lo strumento necessario. Inoltre, ci sono in realtà algoritmi che sono più facili da capire nel multithreading rispetto a quelli con le coroutine semplicemente perché si lascia che il sistema operativo gestisca tutte le domande su dove possono verificarsi interruzioni.
Anche il commento di Candid Moon per attenersi alle coroutine è la mia raccomandazione. Se vuoi il potere dei thread, allora impegnati. Esci e impara davvero le discussioni, formalmente. Abbiamo avuto diversi decenni per capire come organizzare il modo migliore di pensare ai thread in modo da ottenere risultati affidabili ripetibili e affidabili in anticipo e aggiungere prestazioni mentre procedi. Ad esempio, tutti i corsi sani insegneranno i mutex prima di insegnare le variabili di condizione. Tutti i corsi sani che coprono l'atomica insegneranno completamente i mutex e condizioneranno le variabili prima ancora di menzionare che esiste l'atomica. (Nota: non esiste un tutorial sensato sull'atomica.) Cerca di imparare il threading frammentario e stai chiedendo emicrania.