| Re: system.timer() Kategorie: Programmierung (von Wurl - 4.01.2011 21:41) | ||
| Als Antwort auf Re: system.timer() von Detlef - 4.01.2011 11:35 | ||
| ||
|
> > > Hallo. > > > > > > Das mit dem system.timer() als 32bit long Variable gefällt mir auch nicht so. > > > 32bit entsprechen rund 4Mrd. Millisekunden, also ca. 71500 Minuten oder 1193 Stunden oder 49,7 Tage. > > > Für eine absolute Zeit ist das zu wenig. > > > Sofern system.timer() bei Null startet (wobei ich mir nicht sicher bin) gibt es dann nach knapp 50 Tagen einen Overflow. > > > Zeitvergleiche mit system.timer() werden also kompliziert, weil man den Overflow berücksichtigen muss. > > > Und wenn - wie ich glaube - Werte grö�er 2^31 als Negativ (2er-Komplement) interpretiert werden, dann wird es noch schwieriger. > > > > Ich poste mal den Beitrag von Andre.... > > > > Nicht nur der Timer läuft über, sondern jede Variable. > > somit wird aus 2147483647+1 immer -2147483648 , egal, ob timer oder normale Long-Variable. > > Timervergleiche werden in der Programmierung eigentlich schon immer auf diese Weise gemacht, > > da diese immer funzen. > > Vieleicht lässt sich das am einfachsten mit der Hex-Schreibweise verdeutlichen: > > 0x00000000 bis 0x7FFFFFFF sind die Werte von 0 bis 2147483647 > > 0x80000000 bis 0xFFFFFFFF sind die Werte von -2147483648 bis -1 > > Addierst Du nun bei 0x7FFFFFFF eins dazu, erhäst Du 0x80000000, also -2147483648. > > Addierst Du bei 0xFFFFFFFF (=-1) ein dazu erhälst Du 0. > > Der eigentliche �berlauf findet also von -1 zu 0 statt. > > Bei der Subtraktion verhält sich das ganze genauso. > > > > Wenn Du jetzt system.timer()-timer rechnest, und timer den Wert 2147483000 hat > > und der System-timer bei -214748250 steht, wird also > > -2147482500 - 2147483000 gerechnet. > > Hier kommt es bei der Berechnung zu einem "�berlauf": > > 0x8000047C - 0x7FFFFD78 > > Wie Du siehst aber nicht wirklich. :-) > > Das Ergebis wäre hier 1796 (0x704). > > Ineressant wäre eher der Timerbereich von z.B. -100 zu +50. > > system.timer() - timer: > > 0x00000032 - 0xFFFFFF9C > > Hier findet ein echter �berlauf bei der Berechnung statt. > > Das Ergebis ist aber dennoch +150 > > > > > > > > Alsoalles im grünen Bereich... > > nitraM > > Hallo NitraM > > Danke für die Antwort, genau dieses Wissen hatte ich, als ich den Thread geschrieben hatte. > > Problem: Funktioniert nur nicht. Nach einem "gefühlten" Monat, kommt es zu Fehlern bei > allen Abläufen, die diesen Thread verwenden. Das Testen oder Fehlerprovozieren ist fast unmöglich > da es ja nur alle 50 Tage passiert!. Und ab dann ist bis zum Reset der Wurm drin. > > Den Code hatte ich ja gepostet, weil ich meinen Logikfehler leider nicht finde. > > Viele Grü�e > > Detlef Tja. Das Problem ist ja nicht der �berlauf selbst, oder die Berechnung einer Zeitdifferenz. Das eingentlich fatale ist dann der kleiner/grö�er-Vergleich zweier Werte, weil der spätere dann (nach dem bit31-�berlauf bzw. Vorzeichenwechsel) plötzlich nichtmehr grö�er ist sondern plötzlich unendlich kleiner. Deshalb habe ich vorgeschlagen, eben keine absoluten Zeitstempel zu vergleichen, sondern halt nur mit der Zeitdifferenz seit dem letzten Durchlauf (die sich wie beschrieben trotz �berlauf schön berechnen lässt), die verbleibenden Wartezeiten sukzessiv zu verkürzen.. MfG. p.s.: kann sein dass in meinem Codevorschlag noch ein paar Fehler sind, es war schon sehr spät... | ||
Antwort schreiben Antworten: | ||