View Full Version : Iniziare con la programmazione parallela
Salve a tutti, vorrei iniziare con la programmazione parallela. Potete orientarmi su eventuali linguaggi di programmazione che la supportano, librerie, etc... Premesso che vorrei realizzare software di tipo scientifico, se possibile con interfaccia grafica. Vi ringrazio anticipatamente per le vostre risposte.
Conosco e seguenti linguaggi C,C++,Java (base),Python (base).
mad_hhatter
24-09-2007, 13:43
se per programmazione parallela intendi programmazione multi-threading allora la Java platform implementa nativamente l'infrastruttura necessaria (classe Thread, interfaccia Runnable, meccanismi di mutua esclusione e sincronizzazione, ecc). C e C++ si appoggiano alle librerie native del sistema operativo ospite.
Se invece intendi avere controllo esplicito su un'architettura multi-cpu gestendo a mano le singole unità di elaborazione e i modelli di condivisione e accesso alla memoria puoi cominciare con le librerie MPI
ilsensine
24-09-2007, 13:48
sezione sbagliata, sposto in Programmazione
cdimauro
25-09-2007, 08:22
Salve a tutti, vorrei iniziare con la programmazione parallela. Potete orientarmi su eventuali linguaggi di programmazione che la supportano, librerie, etc... Premesso che vorrei realizzare software di tipo scientifico, se possibile con interfaccia grafica. Vi ringrazio anticipatamente per le vostre risposte.
Conosco e seguenti linguaggi C,C++,Java (base),Python (base).
Python è multithread ma sfrutta soltanto un core di un sistema multicore.
Quindi dovresti lanciare n istanze della tua applicazione, una per ogni core, ed eventualmente sincronizzarle fra loro.
Ci sono già degli esperimenti di "Parallel Python", ma non sono informato quindi non ti saprei indicare nulla al momento.
ilsensine
25-09-2007, 09:19
Python è multithread ma sfrutta soltanto un core di un sistema multicore.
mmm come mai questa limitazione?
ilsensine
25-09-2007, 09:22
mmm come mai questa limitazione?
Ipotizzo da solo: usa forse un multithread cooperativo?
mad_hhatter
25-09-2007, 09:45
cosa intendi per multithread cooperativo?
comunque, ti rispondo per sentito dire perché non sono un programmatore python: mi pare di aver capito che mentre Java mappa un thread in un thread nativo del s.o. ospite, python sviluppa i suoi thread in un unico thread del s.o. sottostante
nuovoUtente86
25-09-2007, 10:28
python come Java è un linguaggio interpretato per cui la concorrenza viene gestita ad un livello di astrazione superiore,ma in realta il processo eseguito sulla CPU è sempre uno,come avveniva anche per Java prima che la jvm supportarse le architetture multi-core....e anche su questo diciamo non è chiaro fino a che punto java lavori in multi-thread.
In sostanza se ci sono 3 thread a,b,c sulla cpu andrà un solo processo in esecuzione che di volta in volta mapperà uno dei thread simulando il multithread.
Penso che per threading cooperativo intendesse l' opposto di preemptive.
nuovoUtente86
25-09-2007, 11:04
No. A tutto.
a cosa è riferito?
mad_hhatter
25-09-2007, 11:17
a cosa è riferito?
penso al fatto che la jvm mappa un thread "logico" in un thread nativo del s.o. ospite. non c'entra niente il supporto multi-core che è totalmente demandato al s.o.
quelo che hai detto sui 3 thread su una sola cpu non c'entra niente: è valido per qualsiasi infrastruttura che permetta il multithread: se il processore è uno non ci sono santi: un solo thread verrà eseguito in un istante
nuovoUtente86
25-09-2007, 11:26
Forse mi sono spiegato male:
a livello di jvm viene gestito il multithread(3,10,100 thread),ma il thread in esecuzione sulla cpu è cmq 1.Le ultime implementazioni della jvm però gestiscono il multithread in modo piu reale rispetto alle architetture dual-core.In pratica solitamente i linguaggi interpretati gestiscono il multithread in un livell superiore ma lo nascondono al sistema operativo,mentra ad esempio il c++ utilizza librerie proprie del sistema per il parallelismo.
mad_hhatter
25-09-2007, 11:29
Forse mi sono spiegato male:
a livello di jvm viene gestito il multithread(3,10,100 thread),ma il thread in esecuzione sulla cpu è cmq 1.Le ultime implementazioni della jvm però gestiscono il multithread in modo piu reale rispetto alle architetture dual-core.In pratica solitamente i linguaggi interpretati gestiscono il multithread in un livell superiore ma lo nascondono al sistema operativo,mentra ad esempio il c++ utilizza librerie proprie del sistema per il parallelismo.
assolutamente no: jvm ha sempre mappato i suoi thread in thread nativi del sistema ospite
Ipotizzo da solo: usa forse un multithread cooperativo?
Python internamente usa in lock globale per l'accesso ad ogni singolo oggetto. Il che uvol dire che praticamente impossibile sfruttare più core da codice python. L'unica eccezione e' che lo faccia un modulo C, ma sempre nell'ambito di una singola chiamata.
nuovoUtente86
25-09-2007, 11:41
ho detto il contrario da qualche parte:
ribadisco il concetto:la jvm gestisce il multithread ma mappa sul sistema operativo il tutto come unico thread ovvero il sistema non conosce nulla circa i termini della gestione della concorrenza,non basabdoti di fatto su librerie di sistema.Ora con i nuovi processori multi-core è cambiato il modo di gestire anche il mapping tra jvm e sistema.
mad_hhatter
25-09-2007, 11:52
ho detto il contrario da qualche parte:
ribadisco il concetto:la jvm gestisce il multithread ma mappa sul sistema operativo il tutto come unico thread ovvero il sistema non conosce nulla circa i termini della gestione della concorrenza,non basabdoti di fatto su librerie di sistema.Ora con i nuovi processori multi-core è cambiato il modo di gestire anche il mapping tra jvm e sistema.
cosa c'entra la gestione della concorrenza? questo è demandato ai meccanismi implementati dalla jvm che eventualmente si appoggia a quelli offerti dal s.o., ma qui stiamo parlando d'altro: un thread java viene mappato su un thread nativo del s.o. (posto che esso supporti il multithreading). se un programma java crea più thread questi vengono mappati su altrettanti thread nativi e sarà il s.o. a schedularli come vuole e ad assegnarli a una certa cpu... la jvm non sa nulla dell'hardware sottostante, altrimenti a che servirebbe la virtual machine?
variabilepippo
25-09-2007, 12:01
la jvm gestisce il multithread ma mappa sul sistema operativo il tutto come unico thread
Non sono un programmatore Java, però sarei interessato ad un riferimento ufficiale che confermi questa affermazione.
http://java.sun.com/docs/hotspot/threads/threads.html
Mi sembra di capire: fino a java 1.1 un solo processo, da 1.2 piu' processi.
nuovoUtente86
25-09-2007, 12:12
cosa c'entra la gestione della concorrenza? questo è demandato ai meccanismi implementati dalla jvm che eventualmente si appoggia a quelli offerti dal s.o., ma qui stiamo parlando d'altro: un thread java viene mappato su un thread nativo del s.o. (posto che esso supporti il multithreading). se un programma java crea più thread questi vengono mappati su altrettanti thread nativi e sarà il s.o. a schedularli come vuole e ad assegnarli a una certa cpu... la jvm non sa nulla dell'hardware sottostante, altrimenti a che servirebbe la virtual machine?
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.
Schedulato a livello JVM, conosce solo la JVM... ma San Giosafatte, ma guardate i sorgenti! Si chiama OPEN jdk perchè è OPEN source.
nuovoUtente86
25-09-2007, 12:45
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.
La mia argomentazione è: leggi i sorgenti del JDK perchè è evidente che non l'hai mai fatto.
mad_hhatter
25-09-2007, 13:18
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
25-09-2007, 13:36
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. :cool:
cdimauro
25-09-2007, 14:04
Ipotizzo da solo: usa forse un multithread cooperativo?
Marco ti ha già risposto, io aggiungo soltanto questo http://www.artima.com/forums/flat.jsp?forum=106&thread=214235 per i dettagli. :)
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/second_edition/html/Concepts.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
25-09-2007, 15:30
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/second_edition/html/Concepts.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?
La JVM Hot Spot 7 di Sun Microsystem non si occupa dello scheduling.
nuovoUtente86
25-09-2007, 16:51
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/RetiDiCalcolatori/reti20002001/Javathread00.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/RetiDiCalcolatori/JavaThread.pdf
pag 3
http://lass.cs.umass.edu/~shenoy/courses/fall01/labs/talab2.html
da notare:
In some sense, the JVM scheduler acts like a kernel CPU scheduler
Sei tremendo sei :D. 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
25-09-2007, 17:08
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.....:D
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
25-09-2007, 17:30
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
25-09-2007, 17:32
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
25-09-2007, 17:56
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
da un tutorial della Java Italian Association: :nera:
variabilepippo
25-09-2007, 18:12
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. :cry:
nuovoUtente86
25-09-2007, 18:55
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. :cry:
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
25-09-2007, 19:01
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
25-09-2007, 19:14
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.
variabilepippo
25-09-2007, 19:22
Il contenuto di quello che tu a torto denigri è molto interessante
Io NON ho denigrato nulla, ti ho soltanto detto che tra l'originale e la fotocopia preferisco SEMPRE l'originale, indipendentemente dalla perizia e dal blasone della copisteria.
Tornando in-topic: non ho ancora capito chi ha ragione su come Java gestisca i thread.
mad_hhatter
25-09-2007, 20:38
nessuno :D
dipende tutto dall'implementazione della jvm... le specifiche della jvm non dicono come DEVONO essere gestiti, ma come POSSONO essere gestiti... quindi demandano la decisione alle particolari implementazioni...
dal documento di Sun su solaris emerge che hotspot per solaris oggi (io lascerei perdere la preistoria di java ormai) mappa i thread java in thread nativi... io dai miei studi universitari ricordo che le dispense del corso di s.o. dicevano che hotspot per win32 e linux mappa thread java in thread nativi (ma sono fonti non ufficiali)... cio' non toglie che possono esserci implementazioni della jvm che soltanto simulano il multithreading (magari perche" pensate per s.o. che non supportano il multithreading)
nuovoUtente86
25-09-2007, 20:40
http://www.di.unipi.it/~marcod/disp2.pdf
pag 80-81
entrambe le teorie sono valide...la Sun ha cambiato la gestione da green-thread a mapping con thread nativi.
nuovoUtente86
25-09-2007, 20:52
nessuno :D
dipende tutto dall'implementazione della jvm... le specifiche della jvm non dicono come DEVONO essere gestiti, ma come POSSONO essere gestiti... quindi demandano la decisione alle particolari implementazioni...
dal documento di Sun su solaris emerge che hotspot per solaris oggi (io lascerei perdere la preistoria di java ormai) mappa i thread java in thread nativi... io dai miei studi universitari ricordo che le dispense del corso di s.o. dicevano che hotspot per win32 e linux mappa thread java in thread nativi (ma sono fonti non ufficiali)... cio' non toglie che possono esserci implementazioni della jvm che soltanto simulano il multithreading (magari perche" pensate per s.o. che non supportano il multithreading)
Questo è un altro problema su cui si potrebbe disquisire per anni..la difformità nel materiale accademico....Nelle dispense dove ho studiato io e in quelle che ho postato si fa riferimento ai soli green-thread.Tanto per fare un esempio piu lampante ecco cosa succede in una dispensa:http://www.dei.unipd.it/corsi/so/no/store/u07aMultiThreadJava.pdf
alla pagina 17 si parla di mapping con thread nativi..2 pagine dopo si parla di scheduler della jvm..ma uno esclude l' altro..mahhh..da aggiungere anhe che con il mapping nativo perdono di importanza anche i valori di priorità dati a livello java ai thread dato che non corrispondono a quelli sistema,ne tantomeno sono uniformi.
mad_hhatter
25-09-2007, 21:39
Questo è un altro problema su cui si potrebbe disquisire per anni..la difformità nel materiale accademico....Nelle dispense dove ho studiato io e in quelle che ho postato si fa riferimento ai soli green-thread.
beh, un documento accademico ha uno scopo diverso dalla documentazione ufficiale di un prodotto... i documenti su cui hai studiato tu potrebbero essere stati vecchi oppure lo scopo di chi li ha scritti era investigare e discutere un certo approccio... il fatto che si riferiscano alla versione 1.1 di java e' emblematico...
e' probabile ad esempio, che a livello accademico e didattico sia molto piu' interessante trattare la gestione dello scheduling della jvm per indagarne il funzionamento piuttosto che dire semplicemente "questo e' lasciato al s.o. e non ci interessa"... proprio in quanto funzionale a un corso di studi di informatica
mad_hhatter
25-09-2007, 21:50
l'ultimo pdf mi e' particolarmente caro essendo del mio professore quindi discutiamone... intanto si fa chiaramente riferimento ad "alcune implementazioni": essendo una serie di lucidi il cui scopo e' fare da supporto a una lezione non hanno la pretesa di completezza ne' di assoluta precisione e chiarezza... sono appunti, non specifiche... inoltre a mio parere la discussione mette insieme cose diverse (non essendo il materiale su cui ho studiato azzardo solo qualche ipotesi):
1) il fatto di poter settare una priorita' non e' in contrasto con il demandare la gestione dei thread al s.o.: semplicemente si chiede a java di chiedere al s.o. di dare al thread una certa priorita' (esistera' una mappa tra il set di priorita' in java e quelle del s.o.)
2) lo scheduling non interviene solo in fase di cambio del contesto da un thread ad un altro... altrettanto importante e' lo scheduling di una coda di thread che sono in attesa di acquisire il lock di una risorsa mutex... in questo caso e' molto probabile che sia la jvm a gestire questa coda e a selezionare il thread da eseguire (pur demandando la gestione fisica del thread al s.o.: le due cose non sono assolutamente in contrasto)
nuovoUtente86
25-09-2007, 22:21
l'ultimo pdf mi e' particolarmente caro essendo del mio professore quindi discutiamone... intanto si fa chiaramente riferimento ad "alcune implementazioni": essendo una serie di lucidi il cui scopo e' fare da supporto a una lezione non hanno la pretesa di completezza ne' di assoluta precisione e chiarezza... sono appunti, non specifiche... inoltre a mio parere la discussione mette insieme cose diverse (non essendo il materiale su cui ho studiato azzardo solo qualche ipotesi):
1) il fatto di poter settare una priorita' non e' in contrasto con il demandare la gestione dei thread al s.o.: semplicemente si chiede a java di chiedere al s.o. di dare al thread una certa priorita' (esistera' una mappa tra il set di priorita' in java e quelle del s.o.)
2) lo scheduling non interviene solo in fase di cambio del contesto da un thread ad un altro... altrettanto importante e' lo scheduling di una coda di thread che sono in attesa di acquisire il lock di una risorsa mutex... in questo caso e' molto probabile che sia la jvm a gestire questa coda e a selezionare il thread da eseguire (pur demandando la gestione fisica del thread al s.o.: le due cose non sono assolutamente in contrasto)
1)ad esempio linux gestisce le priorità senza tenere in considerazioni quelle settate in java,come funzioni sotto win e solaris non so.
2)Non ci troviamo di fronte ad una via di mezzo(quando ci fa comodo diciamo che funziona in un modo poi cambiamo idea...)...le implementazioni sono 2:o si occupa di tutto la jvm o demanda tutto(scheduling compreso).In sostanza quando si chiamo il metodo start nel caso di green-thread si accoda il thread nella coda dei pronti..se si implementa il mapping il thread verrà mappato nativamente e d' ora in poi sarà compito del sistema eseguirlo.Diverso il discorso di uno scheduler di supporto che aiuti in qualche modo quello del S:O..ma m sembra sia stato detto qualche post fa che le attuali jvm o almeno alcune attuali implementazioni non utilizzano scheduler di nessun tipo per i thread
Ho perso di vista il problema...mi sembra o state ripetendo la stessa cosa da diversi post ? :Prrr:
A quanto sembra la Sun lascia libera l'implementazione. L'implementazione può far uso di green-thread o può demandare la gestione dei thread al SO. E fin qui l'avete detto anche voi.
Qual è la domanda ?
mad_hhatter
26-09-2007, 08:44
1)ad esempio linux gestisce le priorità senza tenere in considerazioni quelle settate in java,come funzioni sotto win e solaris non so.
2)Non ci troviamo di fronte ad una via di mezzo(quando ci fa comodo diciamo che funziona in un modo poi cambiamo idea...)...le implementazioni sono 2:o si occupa di tutto la jvm o demanda tutto(scheduling compreso).In sostanza quando si chiamo il metodo start nel caso di green-thread si accoda il thread nella coda dei pronti..se si implementa il mapping il thread verrà mappato nativamente e d' ora in poi sarà compito del sistema eseguirlo.Diverso il discorso di uno scheduler di supporto che aiuti in qualche modo quello del S:O..ma m sembra sia stato detto qualche post fa che le attuali jvm o almeno alcune attuali implementazioni non utilizzano scheduler di nessun tipo per i thread
guarda che qua nessuno risponde a comodo: una cosa è o non è.
1) in linux si possono settare varie priorità di esecuzione per un thread? si, e allora la jvm semplicemente mappa le sue priorità nelle priorità disponibili in linux... almeno in teoria... poi come dice PGI-bis per fugare ogni dubbio dobbiamo per forza di cose legegre i sorgenti
2) gestire l'esecuzione di un thread è cosa ben diversa dal gestire la concorrenza e l'accesso a risorse mutex... in entrambi i casi si parla di scheduling, ma si intendono cose leggermente diverse... uno scheduler dei miei thread lo posso fare anch'io all'interno del mio programma. posso gestire l'esecuzione dei thread a mio piacimento bloccandone alcuni e lasciando andare avanti altri... ovvio che il sistema sottostante gestirà nativamente i thread in esecuzione con il suo scheduler, ma le due cose non sono in contraddizione: agiscono a livelli diversi... non so perché questa cosa ti stia tanto sullo stomaco
mad_hhatter
26-09-2007, 08:47
Ho perso di vista il problema...mi sembra o state ripetendo la stessa cosa da diversi post ? :Prrr:
A quanto sembra la Sun lascia libera l'implementazione. L'implementazione può far uso di green-thread o può demandare la gestione dei thread al SO. E fin qui l'avete detto anche voi.
Qual è la domanda ?
credo :D la questione sia se la jvm implementi un suo scheduler e come questo si inserisca nel contesto in cui la stessa jvm mappi i thread java nei thread nativi del s.o. ospite: come conciliare lo scheduling della jvm con quello del s.o.
nuovoUtente86
26-09-2007, 09:24
guarda che qua nessuno risponde a comodo: una cosa è o non è.
1) in linux si possono settare varie priorità di esecuzione per un thread? si, e allora la jvm semplicemente mappa le sue priorità nelle priorità disponibili in linux... almeno in teoria... poi come dice PGI-bis per fugare ogni dubbio dobbiamo per forza di cose legegre i sorgenti
2) gestire l'esecuzione di un thread è cosa ben diversa dal gestire la concorrenza e l'accesso a risorse mutex... in entrambi i casi si parla di scheduling, ma si intendono cose leggermente diverse... uno scheduler dei miei thread lo posso fare anch'io all'interno del mio programma. posso gestire l'esecuzione dei thread a mio piacimento bloccandone alcuni e lasciando andare avanti altri... ovvio che il sistema sottostante gestirà nativamente i thread in esecuzione con il suo scheduler, ma le due cose non sono in contraddizione: agiscono a livelli diversi... non so perché questa cosa ti stia tanto sullo stomaco
1)come detto su per il caso di linux non esiste alcuna correlazione,probabile che in windows e solaris(dove possono essere creati thread nello spazio utente) si.
2)Parliamo come ben dici di un livello differente ovvero dell' accesso alla risorsa condivisa(che a meno di politiche diverse imposte dal programmatore segue la politica FIFO)..ma il nesso con il mapping dei thread sul sistema è molto flebile o meglio...si limita a far eseguire o meno un thread ma nn dirà di certo al SO quale andare ad eseguire nella prossima scelta
mad_hhatter
26-09-2007, 09:44
1)come detto su per il caso di linux non esiste alcuna correlazione,probabile che in windows e solaris(dove possono essere creati thread nello spazio utente) si.
2)Parliamo come ben dici di un livello differente ovvero dell' accesso alla risorsa condivisa(che a meno di politiche diverse imposte dal programmatore segue la politica FIFO)..ma il nesso con il mapping dei thread sul sistema è molto flebile o meglio...si limita a far eseguire o meno un thread ma nn dirà di certo al SO quale andare ad eseguire nella prossima scelta
scusa ma in linux posso settare la priorità di un thread? mi pare di sì, quindi dove sta il problema?
2) ovvio che non interviene nella scelta effettuata dal s.o., ma se la jvm sospende un thread questo non verrà schedulato nemmeno dal s.o.
è qui la questione: la jvm è un processo come gli altri: se al suo interno esegue uno scheduling questo non controlla lo scheduling effettuato dal s.o. se non nei termini di cui parlavo prima
nuovoUtente86
26-09-2007, 09:51
scusa ma in linux posso settare la priorità di un thread? mi pare di sì, quindi dove sta il problema?
2) ovvio che non interviene nella scelta effettuata dal s.o., ma se la jvm sospende un thread questo non verrà schedulato nemmeno dal s.o.
è qui la questione: la jvm è un processo come gli altri: se al suo interno esegue uno scheduling questo non controlla lo scheduling effettuato dal s.o. se non nei termini di cui parlavo prima
1)esattamente non conosco i particolari ma per come è fatto il sistema delle priorità del kernel di linux,non esiste alcuna corrispondenza con quelle java.
2)Non possiamo parlare in tal caso di scheduling vero e proprio della jvm...in caso limite il thread desiderato come prioritario dalla jvm potrebbe non essere mandato in esecuzione dalle politiche del sistema.
mad_hhatter
26-09-2007, 10:51
1)esattamente non conosco i particolari ma per come è fatto il sistema delle priorità del kernel di linux,non esiste alcuna corrispondenza con quelle java.
2)Non possiamo parlare in tal caso di scheduling vero e proprio della jvm...in caso limite il thread desiderato come prioritario dalla jvm potrebbe non essere mandato in esecuzione dalle politiche del sistema.
vedi: http://www.opensolaris.org/os/article/2005-10-14_a_comparison_of_solaris__linux__and_freebsd_kernels/
in linux uno user thread ha priority-range 100..139. Perché jvm non può mappare le sue priority in priority native?
2) supponi che A sia una risorsa mutex su cui fanno wait() un certo numero di thread aventi priorità diverse. Ora lo stato di A cambia e in seguito a un notify() la jvm può far proseguire 2 thread sospesi T1, T2. Ora supponi anche che priority(T1) > priority(T2). Ovviamente la jvm selezionerà (schedulerà) T1 per l'esecuzione e lascerà T2 suspended... questo è scheduling. Che poi T1 sia effettivamente schedulato dal s.o. è irrilevante
Se, puta caso, qualcuno fosse interessato a vedere come la jvm hotspot gestisca le divergenze di priorità può guardare os_linux.cpp, 2694, os_win32.cpp, 2740, os_solaris.cpp, 3746. Nei dintorni si trovano altre cose interessanti. Ad esempio "hint_no_preempt()", un tentativo della JVM di suggerire una politica di scheduling al sistema operativo (fa qualcosa solo in solaris, per windows e linux è inerte).
nuovoUtente86
26-09-2007, 14:51
vedi: http://www.opensolaris.org/os/article/2005-10-14_a_comparison_of_solaris__linux__and_freebsd_kernels/
in linux uno user thread ha priority-range 100..139. Perché jvm non può mappare le sue priority in priority native?
2) supponi che A sia una risorsa mutex su cui fanno wait() un certo numero di thread aventi priorità diverse. Ora lo stato di A cambia e in seguito a un notify() la jvm può far proseguire 2 thread sospesi T1, T2. Ora supponi anche che priority(T1) > priority(T2). Ovviamente la jvm selezionerà (schedulerà) T1 per l'esecuzione e lascerà T2 suspended... questo è scheduling. Che poi T1 sia effettivamente schedulato dal s.o. è irrilevante
1)Ma che mi risulti linux implementa solo kernel-thread e non gestisca al contrario di unix e solaris gli user-thread,inoltre la priorità di default di un thread linux dovrebbe essere 20.
2)Siamo sempre li..se parliamo di scheduling dei thread le soluzioni sono 2 o se ne occupa la jvm o il SO..che poi la jvm possa assistere il SO per operazioni di sincronizzazione su risorse condivise è assolutamente possibile ma è anche un altro discorso.
nuovoUtente86
26-09-2007, 14:52
Se, puta caso, qualcuno fosse interessato a vedere come la jvm hotspot gestisca le divergenze di priorità può guardare os_linux.cpp, 2694, os_win32.cpp, 2740, os_solaris.cpp, 3746. Nei dintorni si trovano altre cose interessanti. Ad esempio "hint_no_preempt()", un tentativo della JVM di suggerire una politica di scheduling al sistema operativo (fa qualcosa solo in solaris, per windows e linux è inerte).
dovrebbe dipendere dal fatto che solaris utilizzi user-thread
Non credo sia un limite tecnico. Nel codice c'è un "TO-DO" in corrispondenza di quell'hint. Più banalmente direi che non hanno avuto tempo di scrivere le versioni windows-linux.
mad_hhatter
26-09-2007, 15:47
1)Ma che mi risulti linux implementa solo kernel-thread e non gestisca al contrario di unix e solaris gli user-thread,inoltre la priorità di default di un thread linux dovrebbe essere 20.
2)Siamo sempre li..se parliamo di scheduling dei thread le soluzioni sono 2 o se ne occupa la jvm o il SO..che poi la jvm possa assistere il SO per operazioni di sincronizzazione su risorse condivise è assolutamente possibile ma è anche un altro discorso.
1) anche i kernel thread hanno un range di priorità... e comunque anche linux ha gli user thread (anche se, mi par di capire, la loro gestione non è così efficace come in AIX e solaris)
2) scusa è, ma hai appena parlato di kernel e user thread... non vedi che in tal caso ci sono 2 tipi di scheduling? bene, è così assurdo che tra jvm e s.o. possa sussistere un rapporto analogo?
sto soltanto dicendo che dire che la jvm implementa uno scheduler non è in contraddizione con il fatto che anche il s.o. sottostante ne implementi uno suo (indipendente dall'altro): fanno cose diverse a livelli diversi.
nuovoUtente86
26-09-2007, 15:58
1) anche i kernel thread hanno un range di priorità... e comunque anche linux ha gli user thread (anche se, mi par di capire, la loro gestione non è così efficace come in AIX e solaris)
2) scusa è, ma hai appena parlato di kernel e user thread... non vedi che in tal caso ci sono 2 tipi di scheduling? bene, è così assurdo che tra jvm e s.o. possa sussistere un rapporto analogo?
sto soltanto dicendo che dire che la jvm implementa uno scheduler non è in contraddizione con il fatto che anche il s.o. sottostante ne implementi uno suo (indipendente dall'altro): fanno cose diverse a livelli diversi.
1)Linux no ha di per se thread-user..ci sono delle librerie che li implementano e comunque sono sono funzionali come quelli solaris e piu generalmente unix.
2)Se parliamodi opinione potrebbe anche essere valido il tuo ragionamento.se parliamo come mappa i thread la jvm non perchè al momento dello start la jvm demanda tutto al SO.
mad_hhatter
26-09-2007, 16:03
1)Linux no ha di per se thread-user..ci sono delle librerie che li implementano e comunque sono sono funzionali come quelli solaris e piu generalmente unix.
2)Se parliamodi opinione potrebbe anche essere valido il tuo ragionamento.se parliamo come mappa i thread la jvm non perchè al momento dello start la jvm demanda tutto al SO.
1) andiamo ot se iniziamo a discutere di questo. il punto era che la jvm anche su linux ha la possibilità di mappare le sue priorità in quelle del s.o.
2) definisci "tutto" :) detta così la jvm non serva a nulla :D non ti pare?
nuovoUtente86
26-09-2007, 16:12
1) andiamo ot se iniziamo a discutere di questo. il punto era che la jvm anche su linux ha la possibilità di mappare le sue priorità in quelle del s.o.
2) definisci "tutto" :) detta così la jvm non serva a nulla :D non ti pare?
1)si andiamo Ot ma se mi si parla di tuser-thread in linux...è bene specificare come stanno le cose.
2)tutto inteso nel caso dei thread(ci son naturalmente tutta un serie di operazione che la jvm fa per il mapping)..ovviamente la jvm ha le importantissime funzionalità che gia conosciamo,che rappresentano la base di un linguaggio multipiattaforma come java.
mad_hhatter
26-09-2007, 16:25
2) questa discussione mi sta sfiancando :D ... va beh, torniamo ad un esempio di qualche post fa... se un thread, pur nelle condizioni di poter avanzare, viene mantenuto suspended dalla jvm, questa non è forse una forma di scheduling da parte della jvm? esso influenza indirettamente lo scheduler del s.o., ma le scelte effettuate da quest'ultimo relativamente ai thread marcati come active dalla jvm non restano forse indipendenti dalla jvm stessa... in pratica il tutto si potrebbe svolgere così:
jvm: questo thread (t1) potrebbe essere marcato active ma siccome io non voglio dico al s.o. di tenerlo suspended... quest'altro (t2) invece che mi sta molto simpatico e questo (t3) li lascio proseguire e non mi interessa come proseguiranno
questo è scheduling da parte della jvm
ora: lo scheduler del s.o. prima della decisione della jvm ha t1, t2 e t3 sospesi... dopo l'intervento della jvm t2 e t3 vengono marcati active... ora lo scheduler del s.o. può mandarne in esecuzione uno a caso, senza vincoli da parte della jvm... questo è scheduling lato s.o.
non sto dicendo che è così, sto solo dimostrando che PUO' essere così, mentre tu ti chiedevi come conciliare scheduling lato jvm con scheduling lato s.o.
ilsensine
26-09-2007, 16:39
1)Linux no ha di per se thread-user
Giusto per chiarire, non esiste un thread USER o un thread KERNEL. Il thread è uno solo. Capita a volte che giri in user space, altre volte che giri in kernel space. Ma il thread è lo stesso, sempre lui.
Forse intendi che Solaris gestisce il thread switch da user space? E' possibile, ma mi sembrerebbe strano...
mad_hhatter
26-09-2007, 16:46
Giusto per chiarire, non esiste un thread USER o un thread KERNEL. Il thread è uno solo. Capita a volte che giri in user space, altre volte che giri in kernel space. Ma il thread è lo stesso, sempre lui.
Forse intendi che Solaris gestisce il thread switch da user space? E' possibile, ma mi sembrerebbe strano...
mah guarda, neanch'io avevo mai sentito parlare di kernel e user thread così ho cercato un po' in giro e in effetti si distinguono le due implementazioni... credo che uno user-thread sia un'entità cui non corrisponde un'entità mappata dal s.o. ... in pratica è come se il codice in user space simulasse al suo interno (all'interno di un thread vero e proprio) un'infrastruttura multithreading ad hoc privata... tanto che se uno di questi user thread si blocca in attesa di I/O tutti gli altri user thread vengono bloccati proprio perchè il s.o. vede solo il kernel-thread al cui interno vivono gli user thread
nuovoUtente86
26-09-2007, 16:47
Giusto per chiarire, non esiste un thread USER o un thread KERNEL. Il thread è uno solo. Capita a volte che giri in user space, altre volte che giri in kernel space. Ma il thread è lo stesso, sempre lui.
Forse intendi che Solaris gestisce il thread switch da user space? E' possibile, ma mi sembrerebbe strano...
Non sono d' accordo.Nella teoria dei sistemi operativi è ben chiara la distinzione tra thread-user e thread-kernel..le loro differenze e gli svantaggi e i vantaggi che ogni approccio utilizza(unix(sia user che kernel) e linux-windows(solo kernel)).Cosi come per solaris (che poi è un' implementazione unix) è ben chiaro il concetto di user-thread...che viene anche illustrato dallo schema di mapping http://java.sun.com/docs/hotspot/threads/threads.html
ilsensine
26-09-2007, 16:51
mah guarda, neanch'io avevo mai sentito parlare di kernel e user thread così ho cercato un po' in giro e in effetti si distinguono le due implementazioni... credo che uno user-thread sia un'entità cui non corrisponde un'entità mappata dal s.o. ... in pratica è come se il codice in user space simulasse al suo interno (all'interno di un thread vero e proprio) un'infrastruttura multithreading ad hoc privata... tanto che se uno di questi user thread si blocca in attesa di I/O tutti gli altri user thread vengono bloccati proprio perchè il s.o. vede solo il kernel-thread al cui interno vivono gli user thread
Sì possibile (linux tratta i kernel come processi), ma così hai qualche problema nel distribuire diversi thread dello stesso programma su più cpu/core...
ilsensine
26-09-2007, 16:55
Non sono d' accordo.Nella teoria dei sistemi operativi è ben chiara la distinzione tra thread-user e thread-kernel..le loro differenze e gli svantaggi e i vantaggi che ogni approccio utilizza(unix(sia user che kernel) e linux-windows(solo kernel)).Cosi come per solaris (che poi è un' implementazione unix) è ben chiaro il concetto di user-thread...che viene anche illustrato dallo schema di mapping http://java.sun.com/docs/hotspot/threads/threads.html
Linux utilizza un sistema 1:1, il kernel è come una specie di libreria. Non ha senso parlare di kernel o user thread.
nuovoUtente86
26-09-2007, 16:56
infatti avete sollevato 2 problemi abbastanza importanti .
mad_hhatter
26-09-2007, 16:57
Sì possibile (linux tratta i kernel come processi), ma così hai qualche problema nel distribuire diversi thread dello stesso programma su più cpu/core...
infatti gli user thread non possono essere spalmati su più cpu, a meno di gestioni un po' particolari e complesse come quella di solaris che al momento non mi va di approfondire :D
nuovoUtente86
26-09-2007, 17:03
Linux utilizza un sistema 1:1, il kernel è come una specie di libreria. Non ha senso parlare di kernel o user thread.
Nella divisione teorica che di fa si parla di kernel-thread e non esiste in linux,almeno di alcune librerie,il concetto di thread utente.Il fatto che il mapping sia 1.1 rende la cosa abbastanza trasparente.
mad_hhatter
26-09-2007, 17:07
chi ha voglia di chiarirmi qual è, ora, l'oggetto della discussione? mi sono definitivamente perso :D
nuovoUtente86
26-09-2007, 17:11
si sta rasentando l' OT..ma pur sempre di concorrenza stiamo parlando.
nuovoUtente86
26-09-2007, 17:13
infatti gli user thread non possono essere spalmati su più cpu, a meno di gestioni un po' particolari e complesse come quella di solaris che al momento non mi va di approfondire :D
molto interessante che solaris risolva questa problematica
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.