Java e il dispatcher...

[Dark867]

Ciao a tutti, sto studiando i thread in java e ho scoperto che la jvm utilizza uno scheduler fifo con priorità...questo significa che se ci sono 2 o più thread con la stessa priorità il thread in esecuzione può occupare la cpu finché non finisce privandola agli altri. Per ovviare a ciò esiste il metodo yeld() e fin qui mi sembrava chiaro...ho però fatto delle prove e ho scoperto che anche senza yeld() i thread si scambiano tra loro.
Ora, io pensavo che java fosse un'astrazione di una macchina e che quindi avesse il SUO scheduler con le SUE politiche viste sopra.
Anche se su windows ho uno scheduler a divisione di tempo ero convinto che il quanto di tempo si riferisse solo alla jvm, vista come unico processo, e che i thread all'interno avessero una politica propria...ora che ho visto che non è così chiedo:

1)E' la jvm a cambiare scheduler a seconda dell'implementazione per il dato sistema operativo (quindi in windows abbiamo una jvm round robin, in alcuni sistemi unix una jvm batch,ecc.)
2)Il sistema operativo vede i thread java ed è lui a intervenire indipendentemente dallo scheduler d java

Quale delle 2?Grazie a chi mi risponderà!

[Alex'87]

Originariamente inviato da Dark867
Ciao a tutti, sto studiando i thread in java e ho scoperto che la jvm utilizza uno scheduler fifo con priorità...questo significa che se ci sono 2 o più thread con la stessa priorità il thread in esecuzione può occupare la cpu finché non finisce privandola agli altri.

Non proprio! Se in una applicazioni ci sono 2 o più thread, ognuno verrà eseguito "parallelamente" agli altri (altrimenti non avrebbe senso!).

Originariamente inviato da Dark867 Per ovviare a ciò esiste il metodo yeld() e fin qui mi sembrava chiaro...ho però fatto delle prove e ho scoperto che anche senza yeld() i thread si scambiano tra loro.

yeld serve per lasciare volontariamente la cpu. Se non lo metti (e sarebbe meglio non farlo, a meno di esigenze particolari) ci pensa la jvm ad interrompere momentaneamente un thread per dare il controllo ad un altro thread.

[aironeangelo77]

ANDBIN, tu che sei la bibbia di questo forum, per favore potresti rispondere (sempre se per te non è un fastidio e hai l'occasione per farlo) a questo post (illuminaci tu) che sembra piuttosto interessante come argomento.

Da quello che ricordo io, non mi sembra che i thread vadano perfettamente in parallelo...la cpu li gestisce comunque uno alla volta...è la VM che gestisce la cpu tale da sembrare che i processi vengano eseguiti in parallelo.

[andbin]

Originariamente inviato da Dark867
ho scoperto che la jvm utilizza uno scheduler fifo

Gli algoritmi di scheduling dei thread variano da una implementazione della JVM all'altra e tipicamente si appoggiano anche alle funzionalità/caratteristiche del S.O. (un approccio tipico è quello di "mappare" un thread Java su un thread "nativo" del S.O.).
Quindi no, in generale non si può dire nulla di preciso.

Originariamente inviato da Dark867
questo significa che se ci sono 2 o più thread con la stessa priorità il thread in esecuzione può occupare la cpu finché non finisce privandola agli altri.

No affatto. Tipicamente nella maggior parte delle JVM l'algoritmo di scheduling è di tipo "preemptive" e basato su "priorità".
"preemptive" vuol dire che c'è un time slicing per cui la CPU viene "tolta" ad un thread e data ad un altro thread ad intervalli di tempo massimi/prefissati, motivo per cui un thread non può "dominare" la CPU impedendo la continuazione di altri thread.

Originariamente inviato da Dark867
Per ovviare a ciò esiste il metodo yeld() e fin qui mi sembrava chiaro...

yield() è solo un "suggerimento" per dire: "guarda che ora non mi servirebbe più impegnare la CPU".
Ma una certa implementazione della JVM potrebbe anche ignorare completamente tale suggerimento e quindi non fare nulla di particolare a seguito di un yield().

Ammesso che lo prenda in considerazione, il massimo che potrebbe fare è far passare il thread dallo stato "running" (in esecuzione) a "runnable" (non è in esecuzione ma può essere eseguito). E tuttavia nulla vieterebbe che lo scheduler lo riscelga subito immediatamente dopo per farlo tornare in running (risultato: lo yield sarebbe servito a poco/nulla).

Originariamente inviato da Dark867
ho però fatto delle prove e ho scoperto che anche senza yeld() i thread si scambiano tra loro.

Se intendi dire che più thread "sembra" che viaggiano in parallelo (anche se la CPU/core fosse 1 solo), sì, è dovuto proprio allo scheduling "preemptive".

Originariamente inviato da Dark867
Ora, io pensavo che java fosse un'astrazione di una macchina e che quindi avesse il SUO scheduler con le SUE politiche viste sopra.
Anche se su windows ho uno scheduler a divisione di tempo ero convinto che il quanto di tempo si riferisse solo alla jvm, vista come unico processo, e che i thread all'interno avessero una politica propria...

La JVM può avere le sue "policy" di scheduling ma tipicamente si appoggia anche (o del tutto) al threading implementato dal S.O. (giusto perché è più conveniente, immagino ovviamente). Come ho detto sopra.

[Dark867]

Felice di ritrovarti anche su questo forum andbin e grazie delle risposte esaurienti!
Cmq su una cosa non sono d'accordo, anche perché è stata esplicitamente detta all'uni:
l'algoritmo di scheduling di java non è timesharing! Per "preemptive" si intende semplicemente la caratteristica di java di togliere la cpu a un thread nel caso in cui ne subentri uno a priorità maggiore, ma solo in questa evenienza!
Quello che dici tu sullo slicing e sui quanti di tempo destinati a ciascun thread si chiama round robin o più in generale politica time sharing e java non ha niente del genere tant'è vero che esiste proprio un caso chiamato "selfish thread", in cui un thread occupa la cpu per non rilasciarla per molto tempo se non quando ha finito o subentra thread a priorità maggiore.

Per il resto tutto ok

[andbin]

Originariamente inviato da Dark867
l'algoritmo di scheduling di java non è timesharing!

E chi ha detto sta cosa???
Lo ripeto ancora una volta. Gli algoritmi di scheduling variano da una implementazione della JVM all'altra. Quindi in generale non si può dire nulla di preciso.
Se mi parlassi in modo più dettagliato e mi dicessi "la JVM X prodotta dalla azienda Y e sviluppata per la piattaforma Z non usa uno scheduling preemptive" allora sarebbe un conto.
Altrimenti ..... no.

Originariamente inviato da Dark867
Per "preemptive" si intende semplicemente la caratteristica di java di togliere la cpu a un thread nel caso in cui ne subentri uno a priorità maggiore, ma solo in questa evenienza!

No .. allora chiariamo.
La questione delle priorità è questa: se vai a vedere nella documentazione della classe Thread ci trovi 3 costanti, tra cui MIN_PRIORITY (che ha valore 1) e MAX_PRIORITY (che ha valore 10). In pratica sono rappresentabili e usabili 10 livelli di priorità.
Una certa implementazione della JVM però potrebbe anche non gestire una tale "granularità" con 10 livelli!! Potrebbe ad esempio gestirne solo 5 o 2 o 1 solo. Dipende da come è implementata e su cosa/come si "appoggia" (come S.O.).
Se la granularità realmente supportata fosse meno di 10, si hanno dei ovvi raggruppamenti. Es. per 2 livelli reali di priorità, i livelli rappresentabili 1-5 potrebbero dare lo stesso risultato e 6-10 idem.
Quindi già questa non è una garanzia e non ci si può fare affidamento più di tanto.

Se la JVM usa uno scheduling con priorità, allora succede una cosa importante: se un thread entra in stato "runnable" e ha una priorità maggiore di quelli nel "pool" di thread e anche maggiore del thread in esecuzione, allora il thread a priorità più bassa viene tolto dal running (tornando in runnable) per dare la precedenza a quello a priorità maggiore.

Quello che non è garantito è cosa succede se 2 thread hanno la stessa priorità. Una implementazione della JVM è libera di fare quello che vuole, che potrebbe essere:

a) Scegliere un thread e permettergli di "dominare" la CPU quanto vuole fino a che termina o arriva ad un punto di blocco/wait.
oppure
b) Dare ai thread una (più o meno) equa opportunità di esecuzione (e questo vuol dire appunto "time slicing").

Originariamente inviato da Dark867
Quello che dici tu sullo slicing e sui quanti di tempo destinati a ciascun thread si chiama round robin o più in generale politica time sharing

Anche qui chiariamo:

- "preemptive" vuol solo e semplicemente dire che il sistema interrompe un task/thread senza che il task/thread stesso debba "cooperare" in qualche modo. Insomma, la interruzione è "forzata" dal sistema, che quindi ha il pieno controllo di quando/quanto far eseguire le cose.

- "round robin" è uno degli algoritmi di scheduling più semplici. E se cerchi su wikipedia lo descrive chiaramente: "which assigns time slices to each process in equal portions and in circular order"

Non è che time-slicing ==> round-robin!! No, il contrario: round-robin è un algoritmo che si basa sul time-slicing. Ma possono esserci altri algoritmi di scheduling differenti che si basano comunque sul time-slicing!!

Originariamente inviato da Dark867
e java non ha niente del genere tant'è vero che esiste proprio un caso chiamato "selfish thread", in cui un thread occupa la cpu per non rilasciarla per molto tempo se non quando ha finito o subentra thread a priorità maggiore.

Lo ripeterò fino alla nausea. Cosa viene usato come scheduling dei thread varia e dipende dalla implementazione della JVM.

Originariamente inviato da Dark867
Per il resto tutto ok

Ehm .... non è per dire o criticare .... ma posso suggerirti di documentarti un pochino di più e di non prendere per "oro colato" tutto ciò che altri, magari in modo dubbio, dicono???

[Dark867]

Questa cosa del timesharing me l'hanno detto all'uni quindi non so che dire, a meno di non trovare un riferimento ufficiale...praticamente la jvm non è timesharing e la prelazione avviene soltanto in caso di priorità differenti. Ho chiesto meglio e secondo il mio prof la jvm è una sola (quindi nessuna impl differente da so a so) soltanto si appoggia al sistema operativo. Se il so supporta i thread allora li vede e li schedula secondo il suo algoritmo d scheduling (i meccanismi della priorità restano propri di java cmq), altrimenti è ancora possibile ottenere un time slicing facendo opportuno uso del metodo yeld() e questo può essere utile per rendere il programma totalmente indipendente dalla piattaforma su cui girerà.

Purtroppo la documentazione a proposito non è tantissima..per questo chiedo anche pareri nei forum...

[andbin]

Originariamente inviato da Dark867
praticamente la jvm non è timesharing

Sbagliato. E lo ripeto, ancora una volta: una certa implementazione della JVM potrebbe non sfruttare il timesharing

Originariamente inviato da Dark867
e la prelazione avviene soltanto in caso di priorità differenti.

Questo sì, in generale. L'ho detto io prima e lo dice, in modo conciso, la documentazione della classe java.lang.Thread:

Every thread has a priority. Threads with higher priority are executed in preference to threads with lower priority.

Originariamente inviato da Dark867
secondo il mio prof la jvm è una sola (quindi nessuna impl differente da so a so)

Certo che ci sono differenti JVM, sia diverse implementazioni a seconda del S.O. ed è anche possibile che ci siano più implementazioni della JVM per un certo S.O.!!!
Pensa solo al fatto che per i Mac non è la Sun che si occupa dello sviluppo dei tools e del runtime per Java ma è la Apple che lo fa direttamente. Secondo te sono uguali le JVM Sun e Apple???

Vuoi una lista, anche se non totalmente esaustiva di JVM??

http://en.wikipedia.org/wiki/List_of...rtual_machines

Originariamente inviato da Dark867
altrimenti è ancora possibile ottenere un time slicing facendo opportuno uso del metodo yeld()

Lo ripeto ancora una volta: se yield() sia preso in considerazione o meno e che cosa possa fare realmente dipende dalla implementazione della JVM.

Originariamente inviato da Dark867
e questo può essere utile per rendere il programma totalmente indipendente dalla piattaforma su cui girerà.

Sbagliato. Quando si lavora con i thread bisogna capire che ci sono poche cose "garantite" ... tutto il resto non lo è e presupporre qualunque cosa di particolare o pensare di farci affidamento, può causare solo risultati inaspettati o peggio casini.

E se anche ti mettessi ad "infarcire" i tuoi sorgenti di yield() rischieresti di fare: a) un lavoro inutile, b) codice poco pulito, c) vedendo che il tuo programma "gira" in un certo modo sulla tua macchina saresti a portato a pensare "funziona così anche su altre macchine/S.O." e purtroppo ti sbaglieresti di brutto ...

Originariamente inviato da Dark867
Purtroppo la documentazione a proposito non è tantissima..

La documentazione c'è ....
La questione è che, secondo la mia modesta opinione, non hai affatto le idee chiare e/o non vuoi chiarirtele. E complice di tutto questo è pure un "prof" che ho la sensazione che abbia le idee ancora meno chiare su Java.

No mi spiace veramente .... la discussione sta prendendo una strana (brutta) piega .....