Utente:LoStrangolatore/Java/roba x Multithreading

Processo e thread

C'è un solo processo che fa da "contenitore" per un numero arbitrario di thread... Thread daemon e non-daemon...

eseguire più compiti
eseguire più compiti contemporaneamente
minimizzare i tempi morti: l'efficacia massima dei thread si ha quando sono impegnati ad aspettare con risorse diverse
permettere alla GUI di rispondere (+ link verso Java/AWT e Swing)

non si fa alcuna garanzia sulla tempistica di esecuzione del codice di un thread, ovvero la JVM può interrompere e riprendere il codice in qualunque momento in modo completamente arbitrario.

La regola generale è: sincronizzare attorno alle risorse condivise.

Il mio codice sembra "thread-safe", ma in realtà non usa le sezioni critiche, beh, ma cosa mai potrà succedere di male?

la JLS definisce alcune operazioni come atomiche, tuttavia senza synchronized non si garantisce che i thread risincronizzino la memoria tra di loro (cioè che uno veda gli effetti dell'altro), il che può portare a risultati inconsistenti
instruction reordering da parte del compilatore (cioè quella cosa che il sorgente di un metodo viene compilato a meno di riordinamenti che preservino il funzionamento del codice di quel metodo se non eseguito in concorrenza con alcun altro thread)

sincronizzare su lock che non sono visti da altre classi (pertanto non sincronizzare su this) (se non sbaglio, questo consiglio l'ho letto proprio sul sito della Sun: se è così, metterci la fonte)
sincronizzare attorno a codice che non esce fuori dalla classe (metodi overrideable o di altre classi)

stare attenti quando si mischiano ereditarietà e multithreading
documentare le caratteristiche di ogni classe/interfaccia relativamente al multithreading (= se lo supporta o no), così sarà più facile metterle insieme e avere un punto di riferimento chiaro quando entrerà in gioco il multithreading