Newsgroup: it.comp.java
Titolo: Come diventare un serial killer di thread?

Salve Salvino a tutti! :)
probabilmente il problema è stupido come il titolo
di questo topic, ma non mi viene in mente nessuna
soluzione :/
io ho un main che mi crea un thread e poi si mette
in attesa su
System.in.read();
come posso dall'altro thread interrompere il main?
con l'interrupt non fa una mazza (setta lo stato del
thread a interrupted.. ma senza uscire dalla read)
help *_*

 
come non detto è un baco di java ç_ç
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4514257
cerco un metodo alternativo..
grazie lo stesso ç_ç

 System.in.read();
Usa un sistema non bloccante per leggere lo stream.
Interroghi lo stream con available() e se ci sono caratteri da leggere 
li leggi, altrimenti no.

 ha scritto:

il punto è che io VOGLIO che si blocchi :/
quel main deve stare fermo fino a ordine da tastiera
dell'utente (quindi tastiera) oppure a ordine di un 
suo thread figlio, per poi continuare l'esecuzione 
in seguito a segnale di sblocco ricevuto..
mi sto scervellando ma nn mi viene in mente niente :(

 il punto è che io VOGLIO che si blocchi :/
E perchè?
while(System.in.available() == 0)
{
}
ch = System.in.read();

 writes:
e> while(System.in.available() == 0) {
e> }
e> ch = System.in.read();
Orrore!
-- 
 /\           ___
/___/\_|_|\_|__|___Gian Uberto Lauri_____
  //--\| | \|  |   Integralista GNUslamico
\/                 e coltivatore diretto di Software

 Orrore!
La soluzione o il problema?

emmeesse ha scritto:

La soluzione.

 La soluzione.
Quindi pensi che un bloccare il thread e terminarlo dall'esterno sia la 
soluzione raccomandabile (ammesso che java te ne dia i mezzi)?
Oppure cosa pensi ci sia di "orrendo"? Di principio, intendo.
Niente polemica. Chiedo.

> Orrore!
e> La soluzione o il problema?
La soluzione, mi spiace.  
Java  non   garantisce  di   avere  un  multitasking   preemptive.  Le
implementazioni di alcuni  sistemi lo hanno, in altri  sistemi lo devi
"forzare", atrimenti -a causa di  problemi di non rientranza di alcune
librerie, Motif in primis- va  sul cooperativo, ovvero fintanto che un
thread  ha la cpu  e non  si ferma  gli altri  se la  sognano.  Questo
potrebbe  portare a  situazioni  in cui  il  Thread interrompente  non
riceve neanche la CPU.
Uno yeld() nel loop migliora un po' la situazione.
Rimane il fatto che un thread che NON DOVREBBE consumare CPU ne usa. La
cosa puo` diventare decisamente fastidiosa (i.e. il sistema in generale
"rallenta").
L'introduzione  di  una  Sleep   nel  loop  potrebbe  portare  qualche
miglioramento   da   questo   punto   di   vista.   Ma   probabilmente
l'applicazione potrebbe non essere "piacevole" da usare (i.e. ci mette
un po' ad accorgersi che l'utente ha fatto dell'input)
Ci  sarebbero  le  alternative  degli  InterruptibleChannel,  ne  puoi
ottenere uno da System.in .


 ottenere uno da System.in .
Questa è una risposta sensata.

> ottenere uno da System.in .
e> Questa è una risposta sensata.
Lo so. Anzi, senza nascondere la presunzione, è la risposta sensata :>.
Le  altre  erano  indicazioni   che,  anche  mettendoci  dentro  varie
accortezze si aveva una cattiva soluzione.


 questione di  Motif non  thread safe(*) 
Senza polemica, ma che c'entra?
Possibilmente cercando di rispondere in modo organico. Mi pare sia tu in 
preda ad un eccessivo context switching, non i thread di java... :P

> questione di Motif non thread safe(*)
e> Senza polemica, ma che c'entra? 
C'entra perchè con i green thread il loop che hai scritto non molla la
CPU a nessuno appena l'acchiappa...  Quindi se il thread figlio di cui
paralva fuu, che doveva mandare un  interrupt al main, ha la sfiga che
la  CPU venga  riassegnata al  main,  non avrà  alcuna possibilità  di
interrompere il thread in attesa perché non verrà mai eseguito.


 Vai a quel paese. 
Ok, bastava dirlo che ti interessava polemizzare.

> Vai a quel paese.
e> Ok, bastava dirlo che ti interessava polemizzare.
Rileggi  quello che hai  scritto con  attenzione.  Quello  che risulta
offensivo  e polemico  con la  frase  "Scusa se  ho sopravvalutato  la
platea" sei tu. Impara ad esprimerti meglio, che probabilmente non era
tuo intento essere offensivo, ma lo sei stato.


emmeesse laid this down on his screen :

La cosa orrenda è fare un'attesa attiva anzichè passiva...con il tuo 
while il tuo thread viene sempre schedulato per l'esecuzione, rubando 
cicli di cpu nel caso in cui non ci siano caratteri da leggere...se 
invece tu avessi un'attesa passiva su interrupt da tastiera le cose 
sarebbero nettamente migliori, perchè il tuo thread resta in wait i/o 
senza essere schedulato, lasciando così la cpu libera per altri thread 
fino a quando davvero c'è la necessità di leggere qualcosa.
Ciao

emmeesse (10/01/2007 23:44:58):

Piantaggio di sistema GA-RAN-TI-TO (sotto windows almeno)
-- 
Scientology: se la conosci la eviti, se la conosci non ti uccide...
http://xenu.com-it.net
 - 
http://xenu.freewinds.cx
 - 
http://www.xenu.net
(per rispondere personalmente leva IlDitoDalCulo)
http://www.webalice.it/ech3l0n/HastaLaVictoria.jpg
   -   Siempre!

 Piantaggio di sistema GA-RAN-TI-TO (sotto windows almeno)
Ma perchè solo il sistema? Io direi tutta la rete, sempre che non sia
collegato a internet perchè altrimenti si pianta tutto il pianeta
<grin>
PS: non sto a dire che che non faccia schifo, e nemmeno che non occupi
inutilmente tempo cpu, ma se un thread con un loop piantasse il sistema
si potrebbe anche smettere di usare i thread, non pensi?

 writes:
Fe> ma se un thread con un loop
Fe> piantasse il sistema si potrebbe anche smettere di usare i thread,
Fe> non pensi?
<OT>
E'  vero  che  in Windows  lo  scheduling  dei  thread Java  è  sempre
preemptive.  Bello.
Peccato  che sotto  ci  sia lo  scheduler  dei thread  di Windows  che
prevede livelli di priorità.  All'interno di un medesimo livello credo
che viga il round robin.
Il  divertente è  quello che  succede tra  i vari  livelli:  se esiste
almeno un trhread  ready a livello N, nessuno  dei thread con priorità
minore di N riceverà la CPU.
Quindi  un bel loop  infinito a  priorità 32  (massima) effettivamente
pianta la macchina.
</OT>


 pianta la macchina.
Ricordo che stiamo comunque parlando di java.
Io ho qualche dubbio che java utilizzi, su windows, un base priority
level REALTIME_PRIORITY_CLASS per i suoi thread. Per cui ritengo
quantomeno improbabile che un thread java possa avere in qualche modo
la massima priorità su windows, o una priorità che possa bloccare il
sistema. Ricordo poi che se il thread avesse la massima priorità
basterebbe molto meno di un loop infinito.
Però può darsi che mi sbagli, in tal caso correggetemi.
In ogni modo, un loop infinito in un thread con Thread.MAX_PRIORITY che
appartiene ad un gruppo con Thread.MAX_PRIORITY non blocca la VM ne
tantomeno se ne vedono gli effetti fuori dalla VM (provare), ergo mi
risulta state parlando di un fatto che in java non esiste. Anche qui se
sbaglio correggetemi, ma possibilmente con delle argomentazioni
organiche.

> pianta la macchina.
e> Ricordo che stiamo comunque parlando di java.
Indubbiamente, non per niente avevo messo i tag <OT>.
e>  Io  ho qualche  dubbio  che  java utilizzi,  su  windows, un  base
e> priority level REALTIME_PRIORITY_CLASS per i suoi thread.
Dubito anche io. Oltretutto per quel livello occorrono, se non ricordo
male  (roba   guardata  una  decina   di  anni  fa)  i   privilegi  di
amministratore - o sfruttare un bug :).
e> quantomeno improbabile che un thread java possa avere in qualche
e> modo la massima priorità su windows, o una priorità che possa
e> bloccare il sistema.
Anche a  parer mio. Ti  porta la  CPU al 100%  e forse può  essere una
concausa in situazioni particolari.
E> Ricordo poi che se il thread avesse la massima
e> priorità basterebbe molto meno di un loop infinito.
Una decina di anni fa bastava un numero sufficente di WM_USER sparati
in broadcast...
e> In ogni modo, un loop infinito in un thread con Thread.MAX_PRIORITY
e> che appartiene ad un gruppo con Thread.MAX_PRIORITY non blocca la
e> VM ne tantomeno se ne vedono gli effetti fuori dalla VM (provare),
La VM l'ha scritta gente con le palle :)...
Però non affermerei "di un fatto che in java non esiste" ma di un
fatto patologico.
