Thread.sleep(20) dauert 31ms ?

[Mr. X]

Hallo,

mein Programm war irgendwie sehr langsam, also hab ich mal einen Zeitmesser eingebaut.
Um zu erfahren welche meiner Methoden so lange braucht, hab ich eine nach der anderen rausgenommen,
bis ich bei 0 Methoden war, und das hat mich dann doch sehr verwundert:

long startTime = System.currentTimeMillis();

/*

..

*/

try{Thread.sleep(20);} 
catch(InterruptedException e){}

long usedTime = System.currentTimeMillis() - startTime;
				
System.out.println("Es wurden " + usedTime + "ms benötigt.");

Das Ergebnis:

Es wurden immer so zwischen 31 und 32 ms gebraucht.
Nur für was wurden die 11 - 12 ms Differenz gebraucht?

Danke

Mfg

Mr. X

 

[byte]

Wenn Du einen Thread schlafen legst, dann gibt er die Kontrolle an andere Threads ab. Du kannst aber nicht davon ausgehen, dass der Thread nach der angegebenen Zeit die Kontrolle sofort wiederbekommt. Das hängt vom derzeitig aktiven Thread ab und von etwaigen anderen wartenden Threads. Die einzige Zusicherung ist die, dass der Thread vor Ablauf dieses Zeitraums weitermacht. Du könntest versuchen, in den anderen Threads z.B. durch ein häufiges Thread.yield() das Ergebnis zu beeinflussen, aber selbst das ist nur ein Hint für den Scheduler. Java sowie die gängigen Betriebssystems sind halt keine Echtzeitsysteme, und selbst bei Echtzeitsystemen wird afaik wird Zeit durch Intervalle gehandlet (Ober-, Untergrenzen).

 

[Mr. X]

Hab eigentlich nur diesen Thread. Wie schaffe ich es jetzt, etwas genau alle 20ms zu tun?
Die Differenz von 20 und 31 ms ist immerhin sehr groß..

Wie sieht das jetzt auf anderen Systemen aus? Werden meine Animationen dort noch langsamer?
Hab ich keinerlei Kontrolle über die Ablaufgeschwindigkeit meines Programmes?

Hab schon überlegt ob ich am Ende jedes Durchlaufs die Zeitdifferenz errechne (31-20)
und für diese "fehlende" Zeit die Rechnungen nachhole.

Also zB 10 Rechnungen pro Durchlauf mit 20ms.
Dauert das ganze dann 31ms so werden für die fehlenden 11 ms also ca. 5 Rechnungen nachgeholt.

Das Problem dabei, es wird etwas ungenau (11ms läßt sich nicht Restfrei durch 2 teilen)
und ausserdem Fängt die Animation an zu Ruckeln.

Mfg

Mr. X

 

[byte]

Also das Sleep bewirkt bei Dir dann einfach nur, dass konstant 20 ms lang gar nichts passiert. Die Differenz (11 ms) vergeht dann wohl vor dem Sleep. Dein Problem ist so nicht lösbar. Selbst wenn die Berechnung bei Dir immer genau 11 ms dauert, dann kann das auf einem anderen Rechner schon wieder ganz anders sein.

 

[EOB]

ausserdem hast du mindestens 2 threads ...

gruesse

 

[Bert Brenner]

Schon mal drüber nachgedacht das vielleicht nicht nur das Thread.sleep für die Abweichungen verantwortlich ist, sondern die ungenigkeit durch System.currentTimeMillis?

Siehe auch API, vielleicht solltest du mit nanoTime arbeiten.

Hier noch ein API auszug bzgl. currentTimeMillis()

Returns the current time in milliseconds. Note that while the unit of time of the return value is a millisecond, the granularity of the value depends on the underlying operating system and may be larger. For example, many operating systems measure time in units of tens of milliseconds.

Hier noch ein kleines Beispiel um das Problem zu verdeutlichen:

  public static void main(String[] args) {
    long oldTime=System.currentTimeMillis();
    while (true){
      long newTime = System.currentTimeMillis();
      System.out.println("Diff: " + (newTime - oldTime));
      oldTime = newTime;
    }
  }

 

[Murray]

Siehe auch API, vielleicht solltest du mit nanoTime arbeiten.

nanoTime hat zwar eine höhere Auflösung, aber nicht notwendigerweise auch die Genauigkeit, die diese Auflösung vortäuscht ;-)

Grundsätzlich erfordert der Ansatz, zwischen zwei Operationen eine exakt definierte Zeit verstreichen zu lassen, ein Echtzeitbetriebssystem, was z.B. auf Windows nicht zutrifft. Insofern kann es da nicht funktionieren.

Wenn es sich nicht um allzu kleine Zeitintervalle handelt (also eher im Sekunden als im Millisekundenbereich), dann kann man solche Aufgaben mit java.util.Timer und java.util.TimerTask angehen, aber auch da gibt es keine Garantie.

 

[Ark]

Was Du noch machen könntest, ist das Erhöhen der Priorität deines Threads, so ist zumindest die Wahrscheinlichkeit, dass er drankommt, gestiegen. Man könnte prinzipiell auch mehrere zu dieser Aufgabe synchronisierte Threads starten (sagen wir 100 Stück :lol: ), dann gehören — je nach System — Dir eventuell 1/6 aller auf dem OS laufenden Threads. Aber davon würde ich dringend abraten.

Ein ganz anderer Weg wäre — neben einer hohen Priorität — eine dafür geeignetere Sprache (sprich: Assembler) zu wählen.

MfG
Ark