"Ciao, Amigo! Voglio parlarti della condivisione delle risorse. Attraverso diversi thread, naturalmente.
"Continuo a parlare dei problemi che si verificano quando si lavora con più thread e di come risolverli. Questo non significa che usare i thread sia sbagliato. I thread sono uno strumento molto potente. In effetti, ti permettono di rendere il tuo programma più veloce e uniforme più affidabile. Più un programma è complesso, più thread e varie parti indipendenti ha."
"Dividere un programma in parti indipendenti (debolmente accoppiate) è molto vantaggioso."
"Immagina che il tuo programma sia suddiviso internamente in 100 thread. Ma hai solo un processore dual-core. Ciò significa che in media verranno eseguiti 50 thread su ciascun core."
"Se hai bisogno di aumentare le prestazioni del programma, devi solo acquistare un server a doppio processore e un paio di processori utili. Questo potrebbe portarti fino a 32 core, ottenendo un aumento delle prestazioni da 2 a 20 volte. A seconda del numero di parti veramente indipendenti in cui è diviso”.
"Questo è uno dei motivi per cui Java domina nello sviluppo aziendale. Se un'azienda ha un programma interno complesso scritto da 20 sviluppatori, allora è molto più economico acquistare un altro server piuttosto che raddoppiare le prestazioni del programma attraverso l'ottimizzazione."
"Quindi è di questo che si tratta."
"Ma! Ogni volta che uno sviluppatore decide di utilizzare un altro thread, risolve un problema e ne crea due. Un numero sempre maggiore di thread non aumenterà all'infinito le prestazioni del programma."
"In primo luogo, qualsiasi programma ha un lavoro che non può essere suddiviso ed eseguito in parallelo su thread diversi. In secondo luogo, tutti i thread vengono eseguiti sullo stesso processore. Più thread hai, più lentamente ognuno funziona."
"E, cosa più importante, i thread usano spesso gli stessi oggetti (di solito chiamati 'risorse condivise')."
"Ad esempio, un thread vuole salvare le informazioni sul lavoro che ha completato in un file. Se ci sono diversi thread di questo tipo e vogliono scrivere informazioni sullo stesso file, interferiranno l'uno con l'altro. Per evitare che il file diventi un file pasticcio confuso, l'accesso al file è limitato, cioè mentre un thread usa il file, gli altri aspettano."
"Sì, mi ricordo. Lo fai usando la parola chiave sincronizzata ."
"Completamente giusto."
"E se i thread scrivono su file diversi?"
"Formalmente, si tratta di oggetti diversi, ma probabilmente si trovano sullo stesso disco rigido."
"Quindi, è davvero possibile parallelizzare qualcosa all'interno del processore?"
"Tecnicamente, sì, ma non appena il tuo thread ha bisogno di qualcosa oltre ai dati che ha, quel qualcosa potrebbe già essere occupato da un altro thread e il tuo thread dovrà aspettare."
"Bene, allora cosa dovrei fare? Come faccio a sapere se devo fare molti fili o no?"
"Questo è determinato direttamente dall'architettura del tuo programma. Ogni progetto ha il suo 'architetto' che conosce tutte le 'risorse' utilizzate nel programma, conosce i loro limiti e quanto bene/male sono parallelizzati."
"E se non lo so?"
"Ci sono due opzioni:"
a) lavorare sotto la supervisione di qualcuno che lo fa
b) ottenere alcuni grumi per capirlo da soli
"Sono un robot: non ho grumi, solo ammaccature."
"Bene, allora, fatti delle ammaccature."
"Capisco. Grazie. Mi hai chiarito alcune cose su cui avevo già iniziato a chiedermi."
GO TO FULL VERSION