Iniziare con la programmazione parallela

[nuovoUtente86]

Originariamente inviato da PGI-Bis

Schedulato a livello JVM, conosce solo la JVM... ma San Giosafatte, ma guardate i sorgenti! Si chiama OPEN jdk perchè è OPEN source.

buttare parole cosi...non serve a nulla.se si ha qualcosa da dire la si argomenta.

[PGI-Bis]

La mia argomentazione è: leggi i sorgenti del JDK perchè è evidente che non l'hai mai fatto.

[mad_hhatter]

Originariamente inviato da nuovoUtente86

1)lA jvm è un' interfaccia tra la macchina e il programmatore,per cui che non sappia nulla dell' ambiante in cui "vive" non è corretto...LA jvm OPERA una virtualizzazione della macchina e per il concetto stesso di virtualizzazione...posso sostituirmi a qualcosa se so come funziona dovendo da una parte dialogare con qualcuno che parla un lnguaggio e "tradurlo" per un altro che capisce un linguaggio differente.
2)Hai un po di confusione circa la gestione dei thread da parte di java.Ogni thread viene schedulato a livello jvm(almeno nelle prime implementazioni...ora non è esattamente cosi)e poi mappato in un thread di sistema..ma il concetto chiave è che il sistema conosce solo la jvm(come se fosse un programma unico).Ancora piu chiaramente con una jvm non progettata(o meglio programmata per sfruttare il multithread) per architetture multi-core...il parallelismo parmane cmq virtuale come se la macchina avesse un solo processore.

allora:
1) la jvm dialoga con il s.o., non con l'hardware. jvm NON sostituisce, jvm ASTRAE un sistema e poi SI APPOGGIA a un s.o. ospite per l'esecuzione "fisica".
2) sicuro? dal documento postato da lovaz:

"Version 1.1 is based on green threads and won't be covered here. Green threads are simulated threads within the VM and were used prior to going to a native OS threading model in 1.2 and beyond. Green threads may have had an advantage on Linux at one point (since you don't have to spawn a process for each native thread), but VM technology has advanced significantly since version 1.1 and any benefit green threads had in the past is erased by the performance increases over the years."

forse sei tu che fai un po' confuzione... come fa la jvm a schedulare un thread E POI a mapparlo in un thread nativo??

se poi parli delle prime versioni della preistoria di java o di jvm che non implementano nativamente il multithreading siamo nel campo delle eccezioni, non della norma: sempre dal documento citato prima "The Java programming language is naturally multi-threadedand because of this the underlying OS implementation can make a substantial difference in the performance of your application".

ripeto, hotspot mappa in maniera biunivoca un thread java in un thread nativo per cui un programma java multithreaded risulta in più thread nativi... poi sarà il s.o. ospite a definire cosa sia un thread e come sia gestito... detto altrimenti (sempre dal doc di cui sopra, una volta per tutte): Java threads are really Solaris Threads since we've been using the native OS threading model in the 1.2 VM".

se sei convinto di aver ragione posta le specifiche...

[variabilepippo]

se sei convinto di aver ragione posta le specifiche...

Concordo, così tagliamo la testa al toro una volta per tutte... Anche se, come suggerito giustamente PGI-Bis, si può sempre dare un'occhiata ai sorgenti in caso di dubbio.

[cdimauro]

Originariamente inviato da ilsensine

Ipotizzo da solo: usa forse un multithread cooperativo?

Marco ti ha già risposto, io aggiungo soltanto questo http://www.artima.com/forums/flat.js...&thread=214235 per i dettagli.

[PGI-Bis]

Guardare le specifiche non risolverà i dubbi. Per la JVM vale lo stesso discorso del modello di memoria del linguaggio: c'è scritto cosa è necessario che capiti, il resto è ad libitum.

Ad esempio, Java Virtual Machine Specifications, 2a ed.

http://java.sun.com/docs/books/jvms/...doc.html#33308

the Java virtual machine can support many threads of execution at once

Threads may be supported by having many hardware processors, by time-slicing a single hardware processor, or by time-slicing many hardware processors.

"Può" non significa "deve". Una JVM che non usi le librerie native per la gestione del multi-threading è perfettamente ammissibile.

E' per questo che dico: guardiamo i sorgenti. Perchè la macchina virtuale che potrebbe esistere non è la macchina virtuale che usiamo. La macchina virtuale che usiamo è quella di osThread_Linux, osThread_win32 e osThread_Solaris, di thread_linux_amd64 eccetera eccetera eccetera. E' la dentro che sappiamo se la JVM usa o non usa le librerie native e come e quando le usa.

[nuovoUtente86]

Originariamente inviato da PGI-Bis

Guardare le specifiche non risolverà i dubbi. Per la JVM vale lo stesso discorso del modello di memoria del linguaggio: c'è scritto cosa è necessario che capiti, il resto è ad libitum.

Ad esempio, Java Virtual Machine Specifications, 2a ed.

http://java.sun.com/docs/books/jvms/...doc.html#33308





"Può" non significa "deve". Una JVM che non usi le librerie native per la gestione del multi-threading è perfettamente ammissibile.

E' per questo che dico: guardiamo i sorgenti. Perchè la macchina virtuale che potrebbe esistere non è la macchina virtuale che usiamo. La macchina virtuale che usiamo è quella di osThread_Linux, osThread_win32 e osThread_Solaris, di thread_linux_amd64 eccetera eccetera eccetera. E' la dentro che sappiamo se la JVM usa o non usa le librerie native e come e quando le usa.

Su questo siamo perfettamente d' accordo...un punto su cui non mi è chiara la vstra posizione però è se la jvm schedula(in modo preemptive come prevede lo standard) o meno i thread?

[PGI-Bis]

La JVM Hot Spot 7 di Sun Microsystem non si occupa dello scheduling.

[nuovoUtente86]

Non schedulare i thread nella jvm dovrebbe rientrare nelle ottimizzazioni per il multithread....basta però leggere qualsiasi libro o dispensa dove si parla di thread java per leggere dello scheduler all' interno della jvm
http://www-lia.deis.unibo.it/Courses...vathread00.pdf
pagina 5-6

qua fa accenno sia al mapping nativo che al green-thread pur mantenendo il concetto di scheduler
http://www-lia.deis.unibo.it/Courses...JavaThread.pdf
pag 3

http://lass.cs.umass.edu/~shenoy/cou...bs/talab2.html

da notare:
In some sense, the JVM scheduler acts like a kernel CPU scheduler

[PGI-Bis]

Sei tremendo sei . Non è in quei documenti che devi trovare notizie circa lo scheduling della JVM.

O è indicato nelle specifiche del linguaggio
O è indicato nelle specifiche della JVM
O è nel codice sorgente di una JVM.

Nelle specifiche del linguaggio non è indicata alcuna politica di scheduling. Nelle specifiche della JVM idem. Nel codice sorgente della JVM si vede palesemente che la gestione dei Thread è delegata al sistema operativo sia in Linux, che in Windows che in Solaris.

[nuovoUtente86]

da quando ho leto per la prima volta i thread in Java..fino ad oggi...si è sempre parlato di scheduler a livello jvm...non lo invento io basta aprire un qualsiasi tutorial....Ora ,o sono ammattiti tutti quelli che scrivono oppure funziona o meglio funzionava in quel modo.

Una frase su tutte:
Le specifiche ufficiali della JVM stabiliscono che una VM gestica i thread secondo uno scheduling preemptive

Ora per chi legge questa frase il significato è chiaro...cosi come è vero che ci sono altri documenti in cui il tutto è affidato al sistema operativo...Ora pur essendo vero che la politica di gestione dipende dall' implementazione...non stiamo parlando di calcio o di cucina..per cui si dovrebbe cercare di capire qualcosa di certo in merito.
Partendo dal punto che dall' implementazione dell' open source jvm si evince che sia tutto delegato al sistema....quello che esce dai tutorial in che direzione va letta,nel senso...tutti parlano di scheduler...qualcuno accenna al sistema operativo...come se fosse un segreto o una vergogna dirlo.....

[PGI-Bis]

Guarda, è possibilissimo che io mi sbagli. Non ci sarebbe alcunchè di cui stupirsi. Però io quella frase nelle specifiche della JVM non la vedo così come non vedo una qualche dichiarazione che impedisca la possibilità che una JVM sia non-preemptive.

Posso sbagliarmi: magari c'è scritto e io non lo vedo. Sono andato a rivederle e ancora non trovo questo requisito. Qualcuno lo vede?

[mad_hhatter]

poiché la jvm può essere ospitata da un s.o. che non supporta il multithread, posso pensare che in tal caso questa jvm sia implementata in modo da sopperire alle mancanze del s.o. sottostante e si prende carico di emulare un sistema multithreading che altrimenti non esisterebbe... in tal caso sarà proprio la jvm a dover occuparsi di schedulare i vari thread

[mad_hhatter]

il problema è che la java platform è fatta per offrire ovunque lo stesso sistema virtuale... ma l'interfacciamento tra la jvm e il sistema sottostante dipende dal sistema sottostante... tutto ciò moltiplica le implementazioni della jvm per cui non dobbiamo commettere l'errore di generalizzare il comportamento di UNA implementazione della jvm

[nuovoUtente86]

da un tutorial della Java Italian Association:
"lo switch di contesto tra threads di un programma Java viene effettuato dalla
JVM (Java Virtual Machine)

Ora non è detto che questo sia il modo migliore,ne quello(a ragione probabilmente) utilizzato per le attuali implementazioni,ma sicuramente i thread venivano gestiti dalla jvm

[PGI-Bis]

Originariamente inviato da nuovoUtente86

da un tutorial della Java Italian Association:

[variabilepippo]

Senza entrare nel merito di questa discussione mi chiedo come si possa soltanto pensare di utilizzare un tutorial non ufficiale (sinonimo di fonte ufficiosa, parziale e/o assolutamente inattendibile) per dimostrare qualcosa.

Prima dell'avvento dei tutorial, di Wikipedia e di altre fonti di dubbia attendibilità l'approccio era profondamente diverso.

[nuovoUtente86]

Originariamente inviato da variabilepippo

Senza entrare nel merito di questa discussione mi chiedo come si possa soltanto pensare di utilizzare un tutorial non ufficiale (sinonimo di fonte ufficiosa, parziale e/o assolutamente inattendibile) per dimostrare qualcosa.

Prima dell'avvento dei tutorial, di Wikipedia e di altre fonti di dubbia attendibilità l'approccio era profondamente diverso.

Se tu avessi letto solo l' intestazione delle prime 2 dispense:
dipartimento di informatice e sistemistica di bologna....scusa se è poco..

Ma un' utile letture(Università di Pisa Prof.Danelutto(meglio di wikipidia che dici)chiarisce forse le idee....dove i 2 approcci sono quello iniziale e quello modificato in seguito dalla Sun come anche il link riguardante i thread solaris gia spiegava.
http://www.di.unipi.it/~marcod/disp2.pdf

[variabilepippo]

Se tu avessi letto solo l' intestazione delle prime 2 dispense:
dipartimento di informatice e sistemistica di bologna....scusa se è poco..

Conosco bene il mondo accademico e non mi faccio impressionare da titoli e titoloni, in genere mi interessa analizzare il contenuto dei paper e quando è possibile preferisco risalire direttamente alla fonte originale: specifiche ufficiali e codice sorgente.

In questo caso, mettendo da parte i "tutorial" e le "dispense", cosa c'è scritto nelle fonti ufficiali sulla gestione dei thread in Java?

[nuovoUtente86]

Originariamente inviato da variabilepippo

Conosco bene il mondo accademico e non mi faccio impressionare da titoli e titoloni, in genere mi interessa analizzare il contenuto dei paper e quando è possibile preferisco risalire direttamente alla fonte originale: specifiche ufficiali e codice sorgente.

In questo caso, mettendo da parte i "tutorial" e le "dispense", cosa c'è scritto nelle fonti ufficiali sulla gestione dei thread in Java?

Il contenuto di quello che tu a torto denigri è molto interessante.Soprattutto l' ultimo postato si rifà molto a quello che dice la Sun...ovvero originario utilizzo dei green-Thread successivo passaggio ai thread-Nativi che poi riconduce al discorso iniziale...ovvero con il green-thread non si ha supporto pieno al multithread su architetture con piu processori...con i thread nativi il tutto è demandato al SO che sa come gestire si multithread sia esso su architetture uni-core per cui solo virtuale o su architetture dual-core(multi-core) quindi reale.