Penso che la tua azienda non debba utilizzare il multithreading.
Dopo aver fatto un progetto con multithreading massivo, ho scoperto che due tecniche erano fondamentali per far funzionare le cose. Prima , il codice doveva essere scritto correttamente. Ogni campo doveva essere controllato manualmente per essere sicuro che fosse stato dichiarato correttamente e sincronizzato in modo corretto a qualunque posto indicato. (Attenzione: sto semplificando un po 'le cose qui per mantenere la mia risposta breve - o comunque più breve.) Secondo , il codice doveva essere testato eseguendo il flat out su singolo e macchine multicore - molti minuti usando il 100% di ogni core. (E se usa solo il 2% di ogni core, come spesso accade per me, anche questo è un bug.)
Potresti riuscire a gestirlo, ma la tua organizzazione non può. Anche se hanno capito il problema, cosa che non fanno, non hanno la competenza.
La maggior parte delle lingue fornisce modi per evitarlo. Se si dispone di un lettore di socket, che di solito ha una propria discussione, ottenere le informazioni sul thread principale il più rapidamente e semplicemente possibile. Meglio ancora, cerca le classi / funzioni di sistema che gestiranno la parte del thread della lettura per te. Utilizza una coda che esegue "eventi" uno dopo l'altro, come fa la maggior parte delle API della GUI. (Se necessario, utilizza la coda eventi della GUI API.) Se hai bisogno dell'elaborazione parallela, puoi probabilmente trovare una sorta di "thread di lavoro" che ti consenta di mantenere dati / campi in un singolo thread, gestendo tutti i trasferimenti per te.
Enfatizza tutti i pericoli del multithreading. (Storie spaventose: il mio bug preferito riguardava un paio di righe come: int i = 5; i = i * i; , che ha portato i ad avere un valore di 35. Una che ho visto molto era: if (thing != null) thing.reset(); che lanciava un'eccezione di puntatore nullo.) Penso che il tuo solo la speranza è far loro capire che stanno entrando in un mondo intero, nuovo, strano e che forse dovrebbero fare un grande passo indietro.
Non sono sicuro di come verrà gestito il multithreading dovrebbe . Se il lavoro può essere dato a una persona, e tutto ciò che gettano via se falliscono, bene. Ma una squadra sarà strong quanto il suo membro più debole, e anche un buon programmatore avrà problemi con il multithreading in piena regola. Spero che le persone di lingua troveranno un modo per renderlo sicuro. Ho visto alcuni software utili là fuori. Ma penso che sia meglio evitare il multithreading a meno che il tempo di esecuzione sia fondamentale e un buon programmatore o un provato team sia disponibile.