Newsgroup: it.comp.java
Titolo: native Thread e green Thread

Ho letto in varie pagine web (
p.es
., 
http://www.di.unipi.it/~marcod/Didattica/LPCc/disp2/node24.html
), che non 
sempre l'uso dei thread rende possibile un vero multitasking, in quanto i 
green thread, a differenza dei native thread, prevedono il rilascio del 
processore solo al termine della propria esecuzione, con gli altri thread 
che rimangono, pur pronti all'esecuzione, in attesa.
Solo che l'opzione java -version, che a sentire gli autori della pagina 
dovrebbe dare indicazioni sulla modalità utilizzata dalla JVM (green o 
native), a me dà:
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_02-b09)
Java HotSpot(TM) Client VM (build 1.5.0_02-b09, mixed mode)
o qualcosa del genere, sia su Windows che su Linux. E il comando 
javac -native nomefile.java, indicato in varie pagine web, non risulta 
corretto per il mio compilatore (di nuovo, sia per Windows che per Linux).
Come ci si può assicurare del fatto che i thread siano effettivamente 
native, permettendo così la loro esecuzione "in contemporanea" (o meglio, un 
quanto di tempo processore a testa)? 

 writes:
M> Come ci si puň assicurare del fatto che i thread siano
M> effettivamente native, permettendo cosě la loro esecuzione "in
M> contemporanea" (o meglio, un quanto di tempo processore a testa)?
<attansiun>
Sotto Windows i thread sono nativi e mappati su quelli di sistema.
Sotto  Unix (e Linux)  la musica  cambia. Usualmente  si usano  i gree
thread  sopratutto per  le applicazioni  con GUI  in quanto  AWT sotto
questi  sistemi  č   legato  a  filo  doppio  con   Motif  che  non  č
rientrante...
</attansiun>
-- 
 /\           ___
/___/\_|_|\_|__|___Gian Uberto Lauri_____
  //--\| | \|  |   Integralista GNUslamico
\/                 e coltivatore diretto di Software

 rientrante...
Ma se uno avesse necessità di usare i native thread per un'applicazione 
server su Linux (senza GUI), cosa bisognerebbe fare? Ho visto che esiste 
un'opzione -client o -server al comando java: ha qualcosa a che fare con 
questo discorso? Io avrei bisogno di aprire un thread per ogni client che si 
connette per gestirne le comunicazioni, dove però lo scopo dell'apertura di 
un thread separato è fatta proprio nel tentativo di non bloccare tutte le 
altre comunicazioni se quelle con il singolo client vanno a rilento. 
Assolutamente necessari, quindi i native thread...

 writes:
M> Ma se uno avesse necessità di usare i native thread per
M> un'applicazione server su Linux (senza GUI),
Con HotSpot sotto Linux usa di  default i thread nativi, ma la cosa mi
sa tanto che può generare rogne (i.e. vedi il comportamento del client
JCVS II)


 JCVS II)
Premetto che non ho la minima idea di cosa significhi HotSpot o JCVS II, 
comunque ho fatto una prova: sono riuscito ad aprire 3 thread diversi con 3 
client, senza che l'apertura del secondo e del terzo dovesse attendere il 
termine dell'esecuzione degli altri. Non noto, anzi, particolari differenze 
rispetto a Windows (a parte la maggiore velocità di esecuzione dei 
processi). Sistema operativo: Fedora 4; java 1.5 di Sun Microsystem, 
apertura thread principale con java -jar provaserver.jar.
Ma è proprio sicuro che in Linux i nuovi thread non possano partire prima 
che del termine di quello in esecuzione? A me non sembra.
N.B. Che differenza comporta eseguire i seguenti comandi?
1) java -jar provaserver.jar
2) java -server -jar provaserver.jar
3) java -client -jar provaserver.jar 

http://java.sun.com/j2se/1.5.0/docs/guide/vm/server-class.html

> client JCVS II)
e> Su linux : Se non ricordo male i green thread non erano in realtà
e> processi che condividevano lo stesso user space e quindi li vedevo
e> con un ps -ef mentre i thread nativi non li vedo e devo usare ps
e> -emf ?  ciao PP
Su Linux la gestione il confine tra thread e processi è fluido, quindi
ti capita  di vedere  con ps quelli  che in  realtà sono thread  e non
processi.
I Green  Thread sono gestiti  in modo collaborativo dalla  JVM, quelli
nativi sono preemptive.


> client JCVS II)
M> Premetto che non ho la minima idea di cosa significhi HotSpot
Male.  E' un  compilatore "just  in  time" che,  integrato nella  JVM,
traduce al volo il bytecode in codice nativo.
M> JCVS II,
E'  un client cvs  con interfaccia  swing. Era  posto come  esempio di
applicazione che da rogne.
M> Non
M> noto, anzi, particolari differenze rispetto a Windows (a parte la
M> maggiore velocità di esecuzione dei processi).
Ho detto che ci sono rogne, non che non si può fare.
Le rogne  derivano dal fatto  che AWT, che  è alla base sia  delle GUI
vecchio  stile  che Swing,  sotto  Unix  e  Linux viene  linkato  alle
librerie Motif che non sono thread safe. 
M> Ma è proprio sicuro che in Linux i nuovi thread non possano partire
M> prima che del termine di quello in esecuzione? A me non sembra.
Dipende da che tipo di thread vengono usati.
Con i  Green Thread  la CPU passa  ad un  nuovo thread solo  quando il
thread che ha in mano la CPU la cede o esplicitamente o implicitamente
(i.e. facendo I/O).
Con  i thread  nativi si  seguono le  politiche del  sistema operativo
ospite, che usualmente  prevedono che la CPU venga  tolta ad un thread
dopo la  fine di un quanto  di tempo (timeslice), salvo  che il thread
non la abbia già rilasciata.
