A volte abbiamo davvero bisogno di scegliere un design multi-thread, perché il single-threading bloccherà l'interfaccia utente o bloccherà un altro thread.
Ma a volte l'uso di più thread è solo una delle opzioni, ad esempio, è possibile sostituire il multi-threading con il timer. In tale situazione, è possibile evitare lo sforzo di esaminare il rischio di prestazioni dell'utilizzo del timer e andare direttamente al design multi-thread. Ma come sappiamo, il threading ha molti svantaggi:
- Problema di sincronizzazione.
- Il debug è difficile per il problema di sincronizzazione.
- Problema di deadlock.
Il numero 1 può sempre essere risolto aggiungendo blocchi e il terzo è il più difficile da risolvere, potrebbe essere necessario modificare i livelli di progettazione. Quindi concentriamoci su quando sarà sicuro scegliere il design multi-thread senza problemi di deadlock.
Uso le seguenti regole per giudicare che sia sicuro o meno:
- Il componente ha solo i dati di input e l'interazione delle chiamate con le funzioni di ingresso.
- Oppure il componente ha solo i dati di output e l'interazione con le chiamate di uscita.
- Oppure hai dati di ingresso e di uscita o chiamate di funzione, ma puoi assicurarti che tutti i dati che entrano possano essere gestiti in modo asincrono. (Non riesco a pensare fuori dal caso, perché hai quasi sempre bisogno di sincronizzarti per spingere i dati in una coda.)
Questo ha senso per te, qualsiasi pensiero è benvenuto.