[URGENTE-JAVA 1.5]Programmazione multithreading

ShadowX84 · 17-07-2007, 16:13

Salve,

so, non per esperizenza diretta, che fino a Java 1.4, la più piccola "unità" era il thread.

Avrei la necessità di sapere se da Java 1.5 in poi è stata introdotta "un'entità" più piccola del thread.
Provo a spiegarmi meglio: è possibile suddividere un thread?

Grazie in anticipo a tutti.

andbin · 17-07-2007, 16:23

Quote:

Originariamente inviato da ShadowX84

Avrei la necessità di sapere se da Java 1.5 in poi è stata introdotta "un'entità" più piccola del thread.
Provo a spiegarmi meglio: è possibile suddividere un thread?

No.

Quale è la tua necessità?

PGI-Bis · 17-07-2007, 16:26

A naso direi di no ma bisognerebbe vedere qui cosa si intende per "unità". Se intendiamo unità nel senso di flusso di esecuzione allora il Thread è effettivamente unitario.

Tuttavia il Thread non è un monolite. Alla lontana, è una pila di "frame" dove ogni frame è la rappresentazione dei dati necessari all'esecuzione di un metodo. Man mano che si svolte, il flusso di esecuzione rappresentato dal Thread accumula e decumula questi frame, creati ogni volta che intervenga l'invocazione di un metodo.

Sono in ogni caso ragionamento validi dalla notte dei tempi. Ciò che è cambiato nella storia della piattaforma Java dal punto di vista della concorrenza è stato una definizione più stringente delle norme relative al modello di memoria e, in Java 5, l'introduzione di strumenti di controllo più astratti rispetto alle istruzioni di gestione della concorrenza integrati nel linguaggio. Prima c'era solo "volatile boolean x" oggi c'è anche "java.util.concurrent.atomic.AtomicBoolean x;", giusto per dirne una.

ShadowX84 · 17-07-2007, 16:35

Grazie ad entrambi, sono io che sono un cane... provo a spiegarmi meglio, con un esempio concreto.

(Però non mi chiedete come siamo arrivati a questo livello...che sono in quest'azienda da troppo poco tempo).

Allora, utilizziamo un gestionale sviluppato apposta per la nostra azienda.
Gestionale che è stato spostato sul nuovo server, che è un dual socket equipaggiato con due xeon quad core e 16 GB di Ram.

Ci siamo accorti che il gestionale non è stato sviluppato per sfruttare sistemi multi core (o multi cpu...fate vobis), e di conseguenza abbiamo 1core al 100% e sette core che stanno a grattarsi e ovviamente quando il gestionale è chiamato a fare un lavoro pesante...blocca o per lo meno rallenta (ovviamente) tutti i client che hanno un'istanza del gestionale aperta.

Siccome per il momento è impensabile mettersi a rendere il lato server multithreading, (oltre ad essere un lavoro enorme..a quel punto converrebbe riscriverlo da zero), volevo sapere se c'era modo di poter "spezzare" il thread evitando così che utilizzi soltanto una CPU.

Scusate ancora, ma la fretta non aiuta ad essere molto esplicativi...

andbin · 17-07-2007, 17:15

Quote:

Originariamente inviato da ShadowX84

sul nuovo server, che è un dual socket equipaggiato con due xeon quad core e 16 GB di Ram.

Il sistema che ho sempre sognato di avere ma che non posso permettermi ....

Quote:

Originariamente inviato da ShadowX84

Ci siamo accorti che il gestionale non è stato sviluppato per sfruttare sistemi multi core (o multi cpu...fate vobis), e di conseguenza abbiamo 1core al 100% e sette core che stanno a grattarsi e ovviamente quando il gestionale è chiamato a fare un lavoro pesante...blocca o per lo meno rallenta (ovviamente) tutti i client che hanno un'istanza del gestionale aperta.

Siccome per il momento è impensabile mettersi a rendere il lato server multithreading, (oltre ad essere un lavoro enorme..a quel punto converrebbe riscriverlo da zero), volevo sapere se c'era modo di poter "spezzare" il thread evitando così che utilizzi soltanto una CPU.

Il parallelismo, cioè il poter eseguire più operazioni "contemporaneamente", non è una cosa che si può attivare così su due piedi su del codice già scritto. Va pianificato, studiato e verificato attentamente quando si progetta l'applicazione.
Ci sono questioni per nulla banali che riguardano la sincronizzazione tra thread, accesso a risorse condivise, ecc....

PGI-Bis · 17-07-2007, 17:24

E qui mi sorge una curiosità latente e mai soddisfatta.

Se un programma è multiprocesso (più JVM per la stessa applicazione) nulla questio: è possibile assegnare almeno una JVM per ogni core e via.

Ma se il programma è multithreading (una sola JVM) i diversi Thread possono essere gestiti da diversi core?

Comunque sia, una cosa che forse avete già provato a fare ma la dico lo stesso è usare la JVM server (lanciare l'applicazione con l'opzione -server) e/o distribuire il garbage collector (-XX:+UseParallelGC).

E' possibile che la piattaforma Java che usate stia già girando con questa opzione attivata. Dipende dal sistema operativo perchè la macchina è sicuramente rilevata come server-class (e vorrei vedere

).

andbin · 17-07-2007, 17:41

Quote:

Originariamente inviato da PGI-Bis

Se un programma è multiprocesso (più JVM per la stessa applicazione) nulla questio: è possibile assegnare almeno una JVM per ogni core e via.

Tecnicamente è possibile. Non mi risulta che ci sia una qualche opzione della JVM per fare ciò, ma ad esempio in Win32 è possibile. Ci sono delle API apposite per forzare/impostare su quale/i processore/i un processo/thread può essere eseguito.

Quote:

Originariamente inviato da PGI-Bis

Ma se il programma è multithreading (una sola JVM) i diversi Thread possono essere gestiti da diversi core?

Questo sicuramente! La cosa tipica per una JVM è quella di "mappare" un Thread su un thread nativo del S.O. E il S.O. è certamente in grado di far andare i thread su core diversi.

ShadowX84 · 17-07-2007, 18:06

Intanto grazie di nuovo per le risposte, scusate ma adesso sono a fare l'altro lavoro...quindi organizzarmi le idee mi richiede un pò di tempo...
...allora...vediamo un pò....

Quote:

Originariamente inviato da andbin

Il sistema che ho sempre sognato di avere ma che non posso permettermi ....

Guarda...a meggio quando sono arrivati i nuovi server...con tanto di cestelli S.A.S. con dischi da 15.000 RPM nn credevo ai miei occhi, ero appena arrivato e trovarmi davanti tanta roba mi creava delle palpitazioni...ma..a distanza di qualche mese...guarda...meno male che c'è Oracle a impegnare un pò quelle macchine...sennò...credimi...erano veramente sottosfruttate.

(Dal mio punto di vista ovviamente...ma sai..non essendo il sistemista..il mio p.d.v. vale 0)

Quote:

Originariamente inviato da andbin

Il parallelismo, cioè il poter eseguire più operazioni "contemporaneamente", non è una cosa che si può attivare così su due piedi su del codice già scritto. Va pianificato, studiato e verificato attentamente quando si progetta l'applicazione.
Ci sono questioni per nulla banali che riguardano la sincronizzazione tra thread, accesso a risorse condivise, ecc....

Lo so bene, infatti se dovessimo intervenire sul codice ci sarebbe da mettersi le mani nei capelli, cosa che andrà fatta prima o poi...ma prima di qualche mese non possiamo proprio.
Per questo chiedevo se c'erano delle vie alternative, magari anche meno eleganti...e un pò forzate..per tamponare momentaneamente la situazione...

Quote:

Originariamente inviato da PGI-Bis

E qui mi sorge una curiosità latente e mai soddisfatta.

Se un programma è multiprocesso (più JVM per la stessa applicazione) nulla questio: è possibile assegnare almeno una JVM per ogni core e via.

Che intendi dire?

Quote:

Originariamente inviato da PGI-Bis

Ma se il programma è multithreading (una sola JVM) i diversi Thread possono essere gestiti da diversi core?

vedi sopra...

perdonami...ma sono molto molto in erba in quanto a programmazione...

Quote:

Originariamente inviato da PGI-Bis

Comunque sia, una cosa che forse avete già provato a fare ma la dico lo stesso è usare la JVM server (lanciare l'applicazione con l'opzione -server) e/o distribuire il garbage collector (-XX:+UseParallelGC).

Ancora non abbiamo fatto nulla...il problema è stato posto solo oggi...

Quote:

Originariamente inviato da PGI-Bis

E' possibile che la piattaforma Java che usate stia già girando con questa opzione attivata. Dipende dal sistema operativo perchè la macchina è sicuramente rilevata come server-class (e vorrei vedere

).

Il server monta una Fedora.

Quote:

Originariamente inviato da andbin

Tecnicamente è possibile. Non mi risulta che ci sia una qualche opzione della JVM per fare ciò, ma ad esempio in Win32 è possibile. Ci sono delle API apposite per forzare/impostare su quale/i processore/i un processo/thread può essere eseguito.

Questo sicuramente! La cosa tipica per una JVM è quella di "mappare" un Thread su un thread nativo del S.O. E il S.O. è certamente in grado di far andare i thread su core diversi.

Quindi?

Grazie di nuovo....

PGI-Bis · 17-07-2007, 18:31

Allora, la tabellina di Sun mi dice che su Fedora una Java SE 6 gira come server, per cui il gc è già parallelo.

Giusto per essere sicuri, basta lanciare JConsole e vedere i parametri che riporta nella scheda "VM Summary" (JConsole è incluso nel jdk, si lancia con un jconsole da linea di comando).

Il programma multiprocesso è... due programmi diversi. E' un po' come se anzichè invocare un metodo per salvare del testo su un file tu lanciassi un programma separato per farlo. In questo caso il programma sarebbe multiprocesso.

Limitandosi a fare "new Thread().start()" et similia, il programma è multithread. E' sempre concorrenza ma ad un livello diverso (Thread diversi esistono nello spazio di memoria dello stesso processo).

ShadowX84 · 18-07-2007, 09:43

Sul server ci gira una Fedora A.S. 4, e la versione della JRE è 1.4.1.
(Onestamente credevo/speravo almeno nel 1.5 )

Quote:

Originariamente inviato da PGI-Bis

e/o distribuire il garbage collector (-XX:+UseParallelGC).

Premesso che ancora non abbiamo provato, che cosa cambierebbe concretamente lanciando l'applicazione con "-server"?.

Inoltre: distribuire il garbage collector che cosa comporta?
Mi spiego: L'applicazione iniziaerà ad utilizzare i vari core? Potrebbero subentrare problemi di concorrenza e/ di accessi alla risorse?

^TiGeRShArK^ · 18-07-2007, 11:10

Quote:

Originariamente inviato da ShadowX84

Sul server ci gira una Fedora A.S. 4, e la versione della JRE è 1.4.1.
(Onestamente credevo/speravo almeno nel 1.5 )

Premesso che ancora non abbiamo provato, che cosa cambierebbe concretamente lanciando l'applicazione con "-server"?.

Inoltre: distribuire il garbage collector che cosa comporta?
Mi spiego: L'applicazione iniziaerà ad utilizzare i vari core? Potrebbero subentrare problemi di concorrenza e/ di accessi alla risorse?

Lìapplicazione lanciata con l'opzione server impiegherà un pò di + a partire e utilizzerà + memoria ma sarà + veloce al runtime.
Parallelizzando il Garbage Collector esso girerà su tutti i core.
Ma il guadagno prestazionale cmq sarà minimo perchè il main thread della tua applicazione girerà cmq su un singolo core.

^TiGeRShArK^ · 18-07-2007, 11:14

Quote:

Originariamente inviato da PGI-Bis

E qui mi sorge una curiosità latente e mai soddisfatta.

Se un programma è multiprocesso (più JVM per la stessa applicazione) nulla questio: è possibile assegnare almeno una JVM per ogni core e via.

Si, ma non ha alcun senso.
Ci penseranno lo scheduler e il dispatcher del sistema operativo ad assegnare i Thread associati alle varie VM (ogni VM ha ben + di un Thread) nei vari core, dinamicamente, a seconda dell'utilizzo richiesto e del carico dei processori.
Assegnare staticamente una VM ad un core quasi sicuramente sarà eno efficiente rispetto a lasciare questa assegnazione al SO.

Quote:

Ma se il programma è multithreading (una sola JVM) i diversi Thread possono essere gestiti da diversi core?

Ovviamente si.
In java, al contrario di ruby, i thread sono mappati in thread nativi del SO e quindi vengono gestiti in maniera del tutto trasparente dallo scheduler.

ShadowX84 · 18-07-2007, 11:20

Quote:

Originariamente inviato da ^TiGeRShArK^

Lìapplicazione lanciata con l'opzione server impiegherà un pò di + a partire e utilizzerà + memoria ma sarà + veloce al runtime.
Parallelizzando il Garbage Collector esso girerà su tutti i core.
Ma il guadagno prestazionale cmq sarà minimo perchè il main thread della tua applicazione girerà cmq su un singolo core.

Sono un pò duro lo ammetto....
Non capiso che vantaggi (anche limitati) potrei ottenere smistando il Garbage sui vari core, se poi comunque il main thread, come hai riustamente riportato tu, contnuerà a girare su un unico core.

^TiGeRShArK^ · 18-07-2007, 11:25

Quote:

Originariamente inviato da ShadowX84

Sono un pò duro lo ammetto....
Non capiso che vantaggi (anche limitati) potrei ottenere smistando il Garbage sui vari core, se poi comunque il main thread, come hai riustamente riportato tu, contnuerà a girare su un unico core.

avrai solamente dei leggerissimi vantaggi.
L'unico modo x farlo andare + veloce è riscriverlo per il multi-threading.
Non c'è altro da fare.

ShadowX84 · 18-07-2007, 11:43

Quote:

Originariamente inviato da ^TiGeRShArK^

avrai solamente dei leggerissimi vantaggi.
L'unico modo x farlo andare + veloce è riscriverlo per il multi-threading.
Non c'è altro da fare.

===>

Lo immaginavo.
Non potendo intervenire così pesantemente nel codice allora mi consigli di intervenire momentaneamente sul Garbage Collector?

Comque sia...grazie...

lovaz · 18-07-2007, 12:48

Non e' detto che un compito sia sempre divisibile tra piu' thread...

Per curiosita' cosa fa il programma quando la prima cpu va al 100%?
(ovvero qual e' il "lavoro pesante"?)

ShadowX84 · 18-07-2007, 13:35

Quote:

Originariamente inviato da lovaz

Non e' detto che un compito sia sempre divisibile tra piu' thread...

Lo so, anche il parallelismo ha dei limiti

Quote:

Originariamente inviato da lovaz

Per curiosita' cosa fa il programma quando la prima cpu va al 100%?
(ovvero qual e' il "lavoro pesante"?)

Un esempio può essere la generazione di bolle e fatture (che è una procedura molto corposa).

In pratica vengono generati e stampati i PDF delle bolle e delle fatture (si tratta di qualche migliaio alla volta), ovviamente i dati per l'elaborazione vengo estrapolati da Oracle e quindi come dicevo è un'operazione corposa.

Calcola che questa operazione porta l'utilizzo della CPU al 100% e quindi anche gli altri utenti che devono utilizzare il gestionale (anche per altre funzioni...) risultano rallentate o bloccate.

lovaz · 18-07-2007, 13:59

Quindi presumo che queste fatture, diciamo 1000, vengano generate sequenzialmente
una dopo l'altra? In questo caso dovresti individuare il punto dove viene
avviata la procedura e inserirci un esecutore che smisti in vari thread le varie fatture.

Inoltre questo prog avra' un'interfaccia. Cosa compare mentre viene eseguito tutto questo?

ShadowX84 · 18-07-2007, 14:18

Quote:

Originariamente inviato da lovaz

Quindi presumo che queste fatture, diciamo 1000, vengono generate sequenzialmente
una dopo l'altra? In questo caso dovresti individuare il punto dove viene
avviata la procedura e inserirci un esecutore che smisti in vari thread le varie fatture.

Ok, diciamo che fino a qui ti seguo.
Mi e ti chiedo: così facendo, però mi troverei con un programma enorme singlethread (situazione attuale) ad un programma sempre enorme, strutturato sempre come singlethread con però una procedura adattata all'esecuzione multithread??
Ho inteso bene? Se si, è una cosa fattibile? è salutare? quanto mi potrebbe stravolgere il programma?

Quote:

Originariamente inviato da lovaz

Inoltre questo prog avra' un'interfaccia. Cosa compare mentre viene eseguito tutto questo?

Sinceramente non lo so, in quanto la fatturazione viene lanciata da altre sedi e quindi non so che cosa vedano di preciso loro nello schermo.
A quando ne so io, le loro macchine rallentano in attesa che il gestionale porti a termine le operazioni. (a grandi linee...)

lovaz · 18-07-2007, 14:36

Quote:

Originariamente inviato da ShadowX84

Ok, diciamo che fino a qui ti seguo.
Mi e ti chiedo: così facendo, però mi troverei con un programma enorme singlethread (situazione attuale) ad un programma sempre enorme, strutturato sempre come singlethread con però una procedura adattata all'esecuzione multithread??
Ho inteso bene? Se si, è una cosa fattibile? è salutare? quanto mi potrebbe stravolgere il programma?

Il thread principale, invece di processare tutte le fatture sequenzialmente, distribuira'
la computazione tra piu' thread.

Dovresti trovare la parte di codice incriminata, e cercare di estrarre la parte
che processa una singola fattura in un Runnable, che poi passerai a un esecutore,
ad es. nel vostro caso (8 core) potrebbe andare bene un

Codice:

Executor executor = Executors.newFixedThreadPool(8);

che come puoi leggere dalla documentazione
http://java.sun.com/javase/6/docs/ap...ThreadPool(int)
usa 8 thread per processare i task, accodati con ad esempio:

Codice:

executor.execute(task);

Ovviamente in queso caso il thread principale non si blocchera' ad attendere che
i task siano terminati, quindi bisogna stare attenti...

Per quanto riguarda le prestazioni dei vari tipi di pool dovresti sentire qualcuno
che ne sa di piu', magari un pool "cached" e' piu' performante, non so...

17-07-2007, 16:13	#1
ShadowX84 Senior Member Iscritto dal: Jul 2002 Città: Soci (AR) Messaggi: 842	[URGENTE-JAVA 1.5]Programmazione multithreading Salve, so, non per esperizenza diretta, che fino a Java 1.4, la più piccola "unità" era il thread. Avrei la necessità di sapere se da Java 1.5 in poi è stata introdotta "un'entità" più piccola del thread. Provo a spiegarmi meglio: è possibile suddividere un thread? Grazie in anticipo a tutti. __________________ ...Fatti non foste a viver come bruti ma per seguir virtute e canoscenza... ...Excusatio non petita, accusatio manifesta... Bruno Boschi

17-07-2007, 16:26	#3
PGI-Bis Senior Member Iscritto dal: Nov 2004 Città: Tra Verona e Mantova Messaggi: 4553	A naso direi di no ma bisognerebbe vedere qui cosa si intende per "unità". Se intendiamo unità nel senso di flusso di esecuzione allora il Thread è effettivamente unitario. Tuttavia il Thread non è un monolite. Alla lontana, è una pila di "frame" dove ogni frame è la rappresentazione dei dati necessari all'esecuzione di un metodo. Man mano che si svolte, il flusso di esecuzione rappresentato dal Thread accumula e decumula questi frame, creati ogni volta che intervenga l'invocazione di un metodo. Sono in ogni caso ragionamento validi dalla notte dei tempi. Ciò che è cambiato nella storia della piattaforma Java dal punto di vista della concorrenza è stato una definizione più stringente delle norme relative al modello di memoria e, in Java 5, l'introduzione di strumenti di controllo più astratti rispetto alle istruzioni di gestione della concorrenza integrati nel linguaggio. Prima c'era solo "volatile boolean x" oggi c'è anche "java.util.concurrent.atomic.AtomicBoolean x;", giusto per dirne una. __________________ Uilliam Scecspir ti fa un baffo? Gioffri Cioser era uno straccione? E allora blogga anche tu, in inglese come me!

17-07-2007, 16:35	#4
ShadowX84 Senior Member Iscritto dal: Jul 2002 Città: Soci (AR) Messaggi: 842	Grazie ad entrambi, sono io che sono un cane... provo a spiegarmi meglio, con un esempio concreto. (Però non mi chiedete come siamo arrivati a questo livello...che sono in quest'azienda da troppo poco tempo). Allora, utilizziamo un gestionale sviluppato apposta per la nostra azienda. Gestionale che è stato spostato sul nuovo server, che è un dual socket equipaggiato con due xeon quad core e 16 GB di Ram. Ci siamo accorti che il gestionale non è stato sviluppato per sfruttare sistemi multi core (o multi cpu...fate vobis), e di conseguenza abbiamo 1core al 100% e sette core che stanno a grattarsi e ovviamente quando il gestionale è chiamato a fare un lavoro pesante...blocca o per lo meno rallenta (ovviamente) tutti i client che hanno un'istanza del gestionale aperta. Siccome per il momento è impensabile mettersi a rendere il lato server multithreading, (oltre ad essere un lavoro enorme..a quel punto converrebbe riscriverlo da zero), volevo sapere se c'era modo di poter "spezzare" il thread evitando così che utilizzi soltanto una CPU. Scusate ancora, ma la fretta non aiuta ad essere molto esplicativi... __________________ ...Fatti non foste a viver come bruti ma per seguir virtute e canoscenza... ...Excusatio non petita, accusatio manifesta... Bruno Boschi Ultima modifica di ShadowX84 : 17-07-2007 alle 16:40.

17-07-2007, 17:24	#6
PGI-Bis Senior Member Iscritto dal: Nov 2004 Città: Tra Verona e Mantova Messaggi: 4553	E qui mi sorge una curiosità latente e mai soddisfatta. Se un programma è multiprocesso (più JVM per la stessa applicazione) nulla questio: è possibile assegnare almeno una JVM per ogni core e via. Ma se il programma è multithreading (una sola JVM) i diversi Thread possono essere gestiti da diversi core? Comunque sia, una cosa che forse avete già provato a fare ma la dico lo stesso è usare la JVM server (lanciare l'applicazione con l'opzione -server) e/o distribuire il garbage collector (-XX:+UseParallelGC). E' possibile che la piattaforma Java che usate stia già girando con questa opzione attivata. Dipende dal sistema operativo perchè la macchina è sicuramente rilevata come server-class (e vorrei vedere ). __________________ Uilliam Scecspir ti fa un baffo? Gioffri Cioser era uno straccione? E allora blogga anche tu, in inglese come me!

17-07-2007, 18:31	#9
PGI-Bis Senior Member Iscritto dal: Nov 2004 Città: Tra Verona e Mantova Messaggi: 4553	Allora, la tabellina di Sun mi dice che su Fedora una Java SE 6 gira come server, per cui il gc è già parallelo. Giusto per essere sicuri, basta lanciare JConsole e vedere i parametri che riporta nella scheda "VM Summary" (JConsole è incluso nel jdk, si lancia con un jconsole da linea di comando). Il programma multiprocesso è... due programmi diversi. E' un po' come se anzichè invocare un metodo per salvare del testo su un file tu lanciassi un programma separato per farlo. In questo caso il programma sarebbe multiprocesso. Limitandosi a fare "new Thread().start()" et similia, il programma è multithread. E' sempre concorrenza ma ad un livello diverso (Thread diversi esistono nello spazio di memoria dello stesso processo). __________________ Uilliam Scecspir ti fa un baffo? Gioffri Cioser era uno straccione? E allora blogga anche tu, in inglese come me!

18-07-2007, 12:48	#16
lovaz Senior Member Iscritto dal: Jul 2002 Messaggi: 4334	Non e' detto che un compito sia sempre divisibile tra piu' thread... Per curiosita' cosa fa il programma quando la prima cpu va al 100%? (ovvero qual e' il "lavoro pesante"?) __________________ \|Java Base\| \|Il Mio Blog 1\| \|Il Mio Blog 2\| \|JavaCC in 30 minuti\|

18-07-2007, 13:59	#18
lovaz Senior Member Iscritto dal: Jul 2002 Messaggi: 4334	Quindi presumo che queste fatture, diciamo 1000, vengano generate sequenzialmente una dopo l'altra? In questo caso dovresti individuare il punto dove viene avviata la procedura e inserirci un esecutore che smisti in vari thread le varie fatture. Inoltre questo prog avra' un'interfaccia. Cosa compare mentre viene eseguito tutto questo? __________________ \|Java Base\| \|Il Mio Blog 1\| \|Il Mio Blog 2\| \|JavaCC in 30 minuti\| Ultima modifica di lovaz : 18-07-2007 alle 14:13.

Strumenti
Mostra una versione stampabile Invia questa pagina per email