Newsgroup: it.comp.java
Titolo: Qualsiasi ciclo "mangia" tutto il tempo al processore

Credo che si tratti di un problema di win2k. 
Ma se faccio
public class Dum
{
	public static void main(String[] args)
	{
		while(true){}
	}
}
l'indicatorre del tempo CPU usato si "stampa" al 100% e la macchina si
"siede" paurosamente. Questo sia con il ciclo vuoto che con qualsiasi
"istruzione" non bloccante...
L'unica maniera che ho trovato di "uscirne" č fare
public class Dum
{
	public static void main(String[] args)
	{
		while(true)
		{
			try
			{
				Thread.sleep(0L,1);
				// un solo nanosecondo di 
				// pausa riporta il tempo CPU
				// molto vicino allo zero
			}
			catch(InterruptedException e)
			{}
		}
	}
}
Finchč ho sviluppato con win98 non ho mai riscontrato questo problema.
E' "giusto" che sia cosě, o mi sfugge qualcosa?

 E' "giusto" che sia così, o mi sfugge qualcosa?

Sul mio PC con XP non succede; che JDK hai ?
Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.
D:\java\CyberChatter>java -version
java version "1.4.1_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06)
Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode)

 Credo che si tratti di un problema di win2k. 
Non particolarmente. Cicli come quello si chiamano di "busy waiting" e non 
sono furbi in nessun linguaggio, esattamente perche' tendono a consumare 
risorse di cpu in modo del tutto inutile (mantenendo un thread/processo in 
run state anche quando non fa niente, con tutti gli oneri di context 
switch, core use, eccetera che ne seguono). 
Usare .sleep() (o equivalente) e' la tecnica corretta.
-- 
Fighting for peace is like fucking for virginity
ObjectZone - 
http://space.tin.it/computer/csadun

 }
Se esegui la tua classe con l'opzione -server il compilatore HotSpot si 
accorge che il ciclo non contiene alcuna istruzione utile e 
semplicemente non esegue niente. (Non penso comunque che sia quello che 
interessava fare a te). Vedi:
Java performance vs C/C#/VB/Perl/...
http://www.javaperformancetuning.com/news/qotm028.shtml
Gaetano Bigliardi

Usare .sleep() (o equivalente) e' la tecnica corretta.
Veniamo all'applicazione pratica: un "poll reader" che legge un
carattere alla volta da un flusso asincrono (esempio concreto, un
client di chat...) (non parlarmi di BufferedReader con il suo
readline()... devo ASSOLUTAMENTE evitare chiamate bloccanti...)
InputStream in=chat.getInputStream();
boolean polling=true;
while(polling)
{
	if(in.available())
	{
		enqueue(in.read());
	}
	else
	{
		try
		{
			Thread.sleep(1L);
		}
		catch(InterruptedException e)
		{}
	}
}
Questo ciclo ha il pregio di non essere bloccante, ma ha il difetto di
introdurre alcuni millisecondi di lag (al lag di sleep() aggiunqi i
controlli del gestore dell'eccezione. Questo lag in condizioni di
grande "flusso" è chiaramente percettibile. Non consigliarmi di
abbassare lo sleep() ad un nanosecondo, perchè proprio ieri sera ho
scoperto con approfonditi test che sleep(0L,1) dura ESATTAMENTE quanto
sleep(1L) sulla mia macchina.
Direi che sono in un "cul de sac": o "processor time mangled" al 100%,
oppure "responsiveness visibly affected"...

interessava fare a te). Vedi:
Il ciclo vuoto era un banale esempio, tanto per spazzare il campo da
eventuali bug nel codice eseguito DENTRO il ciclo...
Rispondendo a Cristiano ho fatto un esem pio concreto nel quale dentro
il ciclo c'è un po' di codice la cui esecuzione "il più rapidamente
possibile" cozza con l'esigenza dello sleep();
Grazie comunque.

readline()... devo ASSOLUTAMENTE evitare chiamate bloccanti...)
[CUT]
Giusto per non farmi mai i... miei :-)
Hai già valutato le librerie New Input/Output (NIO)?
http://www.javaworld.com/javaworld/jw-04-2003/jw-0411-select.html
Magari ribaltando la prospettiva... ;-)
HTH
-- 
Ciao
	Fabrizio C.

 readline()... devo ASSOLUTAMENTE evitare chiamate bloccanti...)
Be', il senso di "chiamate bloccanti" non e' che l'I/O si blocchi a priori, 
ma proprio che si blocca finche' non c'e' un carattere disponibile.
Il problema con "chiamate bloccanti" in Java fino all'1.3 e' che in certe 
situazioni _non si potevano sbloccare da programma_ anche quando sarebbe 
desiderabile (tipicamente, come reazione all'utente che preme "cancel" o 
invia un segnale di stop etc).
Cosa diversa e' BufferedReader.readLine() - che aspetta non semplicemente 
un carattere, ma la sequenza di "fine linea" - quind implementa blocca "a 
linee" piuttosto che "a caratteri". 
In sostanza, per limitarti a leggere un carattere, non devi fare un bel 
nulla dal punto di vista dell'attesa: int c=is.read() dove is e' un 
InputStream (o un Reader) aspettera' fino al prossimo carattere disponibile 
e lo ritorna; o, nel momento in cui e' certo che non ci sara' mai carattere 
disponbile (ad esempio, una socket e' chiusa dal client; oppure EOF e' 
incontrato in un file), ritorna -1.
In piu', con l'1.4 e NIO, puoi controllare piu' finemente (da codice) cosa 
succede nel mentre la JVM (ovvero, di solito, il s/o sottostante) sta 
aspettando che un carattere "arrivi".


sleep(1L) sulla mia macchina.
tenta con:
thread.yield();
ovvero dici allo scheduler che rinunci alla CPU cosi' puo' "darla" ad
altri thread. A questo punto il lag dovrebbe ridursi a quello introdotto
dallo scheduler.
ciao
-- 
Seti@Home Java Applets
http://maruko.cjb.net/

>}
questo per evitare che il thread, nel caso in.avaliable() sia sempre
true, faccia un utilizzo della CPU poco "fair" nei confronti degli altri
thread. Se ce lo metti ammetti che dopo ogni read sei disposto a dare
spazio agli altri thread.
Si', e' vero, c'e' lo scheduler per questo ma se hai molti thread che
girano ti accorgerai che tendono a tenersi la cpu per un po' col
risultato di avere un andamento meno fluido di quello che avresti con lo
yield.
