Wie kann ich in einem einfachen Programm (kein Multithread!!) ein Warteschleife
programmieren?
Das Programm soll halt 1 Minute warten und dann wieder einzelne Prüfungen
durchführen.
Vielen Dank für mögliche Hilfestellungen.
Gruß
Reiner Beimdiek
--
__________________________________________________________
News suchen, lesen, schreiben mit http://newsgroups.web.de
Hi!
Auch wenn es keine Schleife ist:
Thread.sleep(60*1000);
Ciao,
Ingo
>> Wie kann ich in einem einfachen Programm (kein Multithread!!) ein Warteschleife
>> programmieren?
>> Das Programm soll halt 1 Minute warten und dann wieder einzelne Prüfungen
>> durchführen.
>> Vielen Dank für mögliche Hilfestellungen.
> Auch wenn es keine Schleife ist:
> Thread.sleep(60*1000);
Wenn schon, dann richtig:
for (int i = 0; i++ < 60; Thread.sleep(1000));
Big scnr ;-)
Ciao
Chris, eigentlich viel zu frueh fuer ein pRoSt
--
"Die Tragik des 20. Jahrhunderts liegt darin, daß es nicht möglich war,
die Theorien von Karl Marx zuerst an Mäusen auszuprobieren."
(Stanislaw Lem)
In article <3bb8...@netnews.web.de>, Reiner Beimdiek says...
> Wie kann ich in einem einfachen Programm (kein Multithread!!) ein Warteschleife
> programmieren?
> Das Programm soll halt 1 Minute warten und dann wieder einzelne Prüfungen
> durchführen.
Wenn's kein Thread ist, geht's relativ einfach:
long time = System.currentTimeMillis()+60000; //systemzeit+60000ms
while (time>System.currentTimeMillis()){;} //waitloop
Ich hoffe das hilft dir weiter.
Gruss,
-Wanja-
Hallo!
>
>>Wie kann ich in einem einfachen Programm (kein Multithread!!) ein
>>Warteschleife programmieren?
>>Das Programm soll halt 1 Minute warten und dann wieder einzelne
>>Prüfungen durchführen.
>>
>
> Wenn's kein Thread ist, geht's relativ einfach:
>
> long time = System.currentTimeMillis()+60000; //systemzeit+60000ms
> while (time>System.currentTimeMillis()){;} //waitloop
Das sollte man lieber nicht machen. Das frisst nur unnötig
Prozessorzeit. Die schon erwähnte Thread.sleep() alternative ist auf
jedem Fall vorzuziehen.
Jan Arne Petersen
>Wenn's kein Thread ist, geht's relativ einfach:
>
>long time = System.currentTimeMillis()+60000; //systemzeit+60000ms
>while (time>System.currentTimeMillis()){;} //waitloop
>
>Ich hoffe das hilft dir weiter.
>
hoffentlich nicht.
wenn du warten mußt verwende keinesfalls eine schleife wie oben erwähnt,
sonder das von Ingo zitierte:
Thread.sleep(xxx)
denn eine schleife hat (jedenfalls auf meinem windows NT rechner) den
effekt, daß der prozessor zu 100% ausgelastet ist und das ganze system
natürlich ordentlich bremst, und wofür? damit das java programm nichts
tut...
also: finger weg von der schleife: verwende den sleep befehl, da
"schläft" das programm dann auch wirklich.
Alex
> > Wenn's kein Thread ist, geht's relativ einfach:
> >
> > long time = System.currentTimeMillis()+60000; //systemzeit+60000ms
> > while (time>System.currentTimeMillis()){;} //waitloop
>
>
> Das sollte man lieber nicht machen. Das frisst nur unnötig
> Prozessorzeit. Die schon erwähnte Thread.sleep() alternative ist auf
> jedem Fall vorzuziehen.
Klaro. Aktives Warten ist generell nie gut und verschwendet
*natürlich* unnötig Zeit.
Aber für ein Programm das nur Quick'n Dirty sein soll, ist es allemal
gut genug.
-Wanja-
> Klaro. Aktives Warten ist generell nie gut und verschwendet
> *natürlich* unnötig Zeit.
> Aber für ein Programm das nur Quick'n Dirty sein soll, ist es allemal
> gut genug.
Naja. Es gibt eine Grenze von "dirty", die man nicht überschreiten
sollte. Was ist denn, wenn der arme Benutzer in der Minute, die er eh'
warten muss, kurz mal in die Newsgroup schauen will? Da wird er viel
Spass haben, mit einem Prozessor, der in der Zeit planlos seine
Schleifen dreht.
Gruß,
Michael
>> > long time = System.currentTimeMillis()+60000; //systemzeit+60000ms
>> > while (time>System.currentTimeMillis()){;} //waitloop
[...]
> Aber für ein Programm das nur Quick'n Dirty sein soll, ist es allemal
> gut genug.
NACK.
das hat gegenüber
try {
Thread.sleep(1000 * 60);
} catch(InterruptedException ie) {
throw new Error("ahhhhhhhhh!\n" + ie);
}
überhaupt keinen vorteil, ist weder intuitiver, noch schneller noch
geschrieben. dat jeht so nöch.
salut,
niko
--
Kiss your keyboard goodbye!
Gerade eine solche Schleife ist auf allen Multitaskingsystemen der
Performancekiller fürs ganze System. Eine Anwendung, die eine solche
Schleife enthält kann man gleich auf den Müll kippen.
Jan Arne Petersen
--
Die Homepage von de.comp.lang.java: http://www.dclj.de
JRuby - Rubyinterpreter für Java: http://jruby.sf.net
[Aktives warten]
> Gerade eine solche Schleife ist auf allen Multitaskingsystemen der
> Performancekiller fürs ganze System. Eine Anwendung, die eine solche
> Schleife enthält kann man gleich auf den Müll kippen.
Ich stimme euch ja allen zu, es ist halt nur so, dass wenn ich mal ein
Programm schreibe und nicht zum Thread greife, auch keinen sleep machen
kann. So und wenn es nur um eine Kleinigkeit geht, dann reicht mir das
allemal. Ich würde sowas nie bei Projekten machen, die ich gross herum
geben möchte. Wenn's aber darum geht ein paar Leuten kurz ein Diagramm zu
präsentieren, dann ist es für den Zweck auch mal herzlich egal, denn in
der Zeit spackt man nicht mit 100 anderen Applikationen herum.
Gruss,
-Wanja-
ps: vielleicht stoppt dieses aktive Warten einen Mac, aber ein preemtives
MT-OS hat damit generell keine Probleme, es ist nicht so, als würde
deswegen plötzlich der Newsreader stehen bleiben (wer kommt denn auf
sowas?)..
Am 08.10.2001 schrieb Wanja Gayk <br...@plush.de> :
> In article <jrnpp9...@ID-91407.user.dfncis.de>, Jan Arne Petersen
> says...
> Ich stimme euch ja allen zu, es ist halt nur so, dass wenn ich mal ein
> Programm schreibe und nicht zum Thread greife, auch keinen sleep machen
> kann.
Also, bei mir ist Thread.sleep(x) static...
> ps: vielleicht stoppt dieses aktive Warten einen Mac, aber ein preemtives
> MT-OS hat damit generell keine Probleme, es ist nicht so, als würde
> deswegen plötzlich der Newsreader stehen bleiben (wer kommt denn auf
> sowas?)..
Woher weißt Du, auf welcher Plattform ein Java-Programm läuft?
Tschüß
Hauke
> Ich stimme euch ja allen zu, es ist halt nur so, dass wenn ich mal ein
> Programm schreibe und nicht zum Thread greife, auch keinen sleep machen
> kann.
Um Thread.sleep(long millis) zu verwenden, brauchst Du nicht "zum Thread
zu greifen". Das ist eine statische Methode der Klasse Thread und sie
legt immer den Thread schlafen, in dem sich die Programmausführung
gerade befindet, also den, der diese Anweisung ausführt. Und den gibt es
sowieso, egal ob du nun explizit "zum Thread greifst" oder ihn nur
implizit startest, indem Du Dein Programm ausführst. Du kannst also
_immer_ "einen Sleep machen".
> So und wenn es nur um eine Kleinigkeit geht, dann reicht mir das
> allemal.
Das ist natürlich Deine Sache. Es in der Newsgroup als Lösung für die
Programmierung einer Warteschleife zu empfehlen, ist hingegen fast schon
gemeingefährlich. Und Deine Versuche, da noch dranherumzureden, sind
schlicht unnötig. Wir haben schließlich alle schon mal Stuss erzählt...
da kann man hier ruhig zu stehen.
> ps: vielleicht stoppt dieses aktive Warten einen Mac, aber ein preemtives
> MT-OS hat damit generell keine Probleme, es ist nicht so, als würde
> deswegen plötzlich der Newsreader stehen bleiben (wer kommt denn auf
> sowas?)..
Aktives Warten verbrät Prozessorzeit und das nicht zu knapp, ist
unschön, unprofessionell und absolut überflüssig (Nein, ich habe keinen
Mac).
Gruß,
Michael
>> So und wenn es nur um eine Kleinigkeit geht, dann reicht mir das
>> allemal.
> Das ist natürlich Deine Sache. Es in der Newsgroup als Lösung für die
> Programmierung einer Warteschleife zu empfehlen, ist hingegen fast schon
> gemeingefährlich. Und Deine Versuche, da noch dranherumzureden, sind
> schlicht unnötig. Wir haben schließlich alle schon mal Stuss erzählt...
> da kann man hier ruhig zu stehen.
Full Ack.... (:-)
>> ps: vielleicht stoppt dieses aktive Warten einen Mac, aber ein preemtives
>> MT-OS hat damit generell keine Probleme, es ist nicht so, als würde
>> deswegen plötzlich der Newsreader stehen bleiben (wer kommt denn auf
>> sowas?)..
> Aktives Warten verbrät Prozessorzeit und das nicht zu knapp, ist
> unschön, unprofessionell und absolut überflüssig (Nein, ich habe keinen
> Mac).
Full Ack^42.
Und davon mal abgesehen weiss ich aus Erfahrung, dass es sowohl ein
SUSE 7.1, ein Solaris ??, ein RedHat ??, ein ME, ein 9x, ein NT und
ein 2k lahmlegt. Mit MacOS sind das nun wieviel Prozent der genutzten
OS? Einzig BeOS und Irix konnte ich noch nicht verfizieren, moechte
aber wetten, dass auch das leiden wird.
Das Problem ist auch, dass so ein aktives Warten meist noch um Laengen
ungenauer ist, als jedes warten auf einem Thread-Monitor es jemals
sein koennte....
Ebenfalls von Bedeutung fuer die Art und Intensitaet der Auswirkungen
ist die Prioritaet, welche der Warte-Thread geniesst....
Ein Idle-Thread wird sicherlich nicht das System lahmlegen, ist dafuer
sehr ungenau; ein Maximum-Thread hingegen ist schon um einiges genauer
(aber immer noch ungenauer als ein sleep) blockiert aber je nach Rechten
des Users mitunter das ganze System.
Fazit: Warteschleifen stammen aus der Prae-Thread-Aera und sind
heutzutage veraltet. Wenn man schon ein MT-OS nutzt, sollte man es
auch richtig nutzen.
Ciao
Chris
--
"Sonderbar, sowie das Weib zum denkenden Selbstbewusstsein
kommt, ist ihr erster Gedanke ein neues Kleid!" (Heinrich Heine *1797)
Das stimmt nicht. Falls dein Programm schon mal unerwartet durch eine
"ungefangene" Ausnahme beendet wurde müsstest du es eigentlich wissen ...
> "Exception in thread "main": java.lang.RuntimeException"
So und "main" ist der Thread, der von der VM erzeugt wurde.
"Thread.sleep(long)" ist statisch und bezieht sich beim Aufruf immer auf den
Thread im aktuellen Kontext.
Gruß,
Sascha
> Um Thread.sleep(long millis) zu verwenden, brauchst Du nicht "zum Thread
> zu greifen". Das ist eine statische Methode der Klasse Thread und sie
> legt immer den Thread schlafen, in dem sich die Programmausführung
> gerade befindet, also den, der diese Anweisung ausführt. Und den gibt es
> sowieso, egal ob du nun explizit "zum Thread greifst" oder ihn nur
> implizit startest, indem Du Dein Programm ausführst. Du kannst also
> _immer_ "einen Sleep machen".
So lerne ich dazu.. Das wusste ich bisher nicht.
> > So und wenn es nur um eine Kleinigkeit geht, dann reicht mir das
> > allemal.
>
> Das ist natürlich Deine Sache. Es in der Newsgroup als Lösung für die
> Programmierung einer Warteschleife zu empfehlen, ist hingegen fast schon
> gemeingefährlich.
Was man so eine "Empfehlung" ist. Ist ja nicht so, dass ich nicht gesagt
hätte, dass es Schmutzig ist.
> Und Deine Versuche, da noch dranherumzureden, sind
> schlicht unnötig. Wir haben schließlich alle schon mal Stuss erzählt...
> da kann man hier ruhig zu stehen.
Steh ich auch zu.
> Aktives Warten verbrät Prozessorzeit und das nicht zu knapp, ist
> unschön, unprofessionell und absolut überflüssig (Nein, ich habe keinen
> Mac).
Da stimme ich dir auch zu und das habe ich auch *nie* angezweifelt.
Gruss,
-Wanja-
> > "Exception in thread "main": java.lang.RuntimeException"
>
> So und "main" ist der Thread, der von der VM erzeugt wurde.
> "Thread.sleep(long)" ist statisch und bezieht sich beim Aufruf immer auf den
> Thread im aktuellen Kontext.
Danke für die Info. Wird mir in Zukunft sicher nützlich sein.
Bisher dachte ich immer, dass der Thread, der durch das Starten des
Hauptprgrammes ausgelöst wird so nicht zu erreichen wäre.
Also nehme ich alles zurück und behaupte das Gegenteil :-)
-Wanja-
> Thread.sleep(xxx)
> also: finger weg von der schleife: verwende den sleep befehl, da
> "schläft" das programm dann auch wirklich.
Ja, aber warum sagt keiner dazu, dass man das so schreiben sollte:
try {
Thread.sleep(1000);
} catch (InterruptedException e) { }
damit der Compiler nicht meckert?
--
Hubert Partl pa...@mail.boku.ac.at
ZID BOKU Wien http://homepage.boku.ac.at/partl/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
if ( music == food(love) ) play_on(); /* night[12-1] */
> Ja, aber warum sagt keiner dazu, dass man das so schreiben sollte:
>
> try {
> Thread.sleep(1000);
> } catch (InterruptedException e) { }
>
> damit der Compiler nicht meckert?
>
>
Weil alle wußten, daß dein dclj-Antwortthread bald ein notify bekommt
und dir noch was übrig bleiben sollte? :)
Micha
--
Homepage & FAQ von de.comp.lang.java: http://www.dclj.de