[Java] Accurate Timer in Java?

[Red devil]

Beste Tweakers,

Voor een project moet ik binnen een ingestelde tijd de complete tekst van een boek voorbij laten scrollen in 8 uur. De applicatie die ik nu gemaakt heb maakt gebruik van 2 Timers in Java. De eerste Timer stuurt de 2e Timer aan. Doordat de 1e Timer de delay van de 2e Timer versteld, krijg je een mooi effect dat de eerste X aantal characters van het boek langzaam voorbijkomen... steeds sneller en sneller.

Het probleem alleen ligt bij de Timer klasse van Java.

This class does not offer real-time guarantees: it schedules tasks using the Object.wait(long) method.

Implementation note: This class scales to large numbers of concurrently scheduled tasks (thousands should present no problem). Internally, it uses a binary heap to represent its task queue, so the cost to schedule a task is O(log n), where n is the number of concurrently scheduled tasks.

Oftewel, leuk voor korte stukjes maar niet voor mij. Het programma hoe snel hij door het boek heen moet wandelen gegeven een bepaalde delay van de timer. Alleen, als je daarna daadwerkelijk gaat kijken hoe lang hij erover doet, varieert dit van 13-15 uur. Hoe krijg ik het nu voor elkaar dat het programma redelijk nauwkeurig in 8 uur tijd het complete boek doorwandelt.

Iemand enig idee?

[.oisyn]

Door de wachttijd af te laten hangen van de tijd die al verstreken is sinds het begin van het programma.

Het punt is, als jij bijvoorbeeld 3x achter elkaar een sleep(2) doet, dan is dat niet hetzelfde als een sleep(6), omdat je in het eerste geval 3x een fout kunt krijgen van een aantal milliseconden, terwijl dat in het tweede geval maar 1 keer kan optreden. Wat je feitelijk wilt, is de eerste keer een sleep tot seconde 2, daarna een sleep tot seconde 4, dan een sleep tot seconde 6. De laatste keer doe je dus: sleep(6 - seconden al verstreken sinds begin van het programma)

Tot op de nanoseconde exact krijg je het natuurlijk nooit, die garanties kan het OS je zelfs niet geven. Maar op deze manier stapelen fouten zich dus niet op, en zal je applicatie dus altijd binnen 8 uur eindigen.

[ Voor 15% gewijzigd door .oisyn op 18-09-2009 13:20 ]

[Red devil]

.oisyn schreef op vrijdag 18 september 2009 @ 13:18:
Door de wachttijd af te laten hangen van de tijd die al verstreken is sinds het begin van het programma.

Het punt is, als jij bijvoorbeeld 3x achter elkaar een sleep(2) doet, dan is dat niet hetzelfde als een sleep(6), omdat je in het eerste geval 3x een fout kunt krijgen van een aantal milliseconden, terwijl dat in het tweede geval maar 1 keer kan optreden. Wat je feitelijk wilt, is de eerste keer een sleep tot seconde 2, daarna een sleep tot seconde 4, dan een sleep tot seconde 6. De laatste keer doe je dus: sleep(6 - seconden al verstreken sinds begin van het programma)

Tot op de nanoseconde exact krijg je het natuurlijk nooit, die garanties kan het OS je zelfs niet geven. Maar op deze manier stapelen fouten zich dus niet op, en zal je applicatie dus altijd binnen 8 uur eindigen.

Ja zoiets moet ik maar maken. Wel weer dom dat ik het niet eerder heb gelezen. Ik maar prutsen met die timings e.d. van die timer

[Nick_S]

Je kan ook eens kijken naar Quartz. Hiermee kun je een timer aanmaken, welke elke x tijdeenheid een event afvuurt / methode aanroept. Dan hoef je zelf niet te gaan rommelen met tijd bijhouden.

[Red devil]

Nick_S schreef op vrijdag 18 september 2009 @ 15:30:
Je kan ook eens kijken naar Quartz. Hiermee kun je een timer aanmaken, welke elke x tijdeenheid een event afvuurt / methode aanroept. Dan hoef je zelf niet te gaan rommelen met tijd bijhouden.

Shit ja dit was makkelijker geweest. Heb nu zelf een hokkiewokkie-implementatie gemaakt.
Als die niet goed werkt (kan maandag pas weer testen) dan ga dit gebruiken. Bedankt ervoor

[Bl4ckviper]

Red devil schreef op vrijdag 18 september 2009 @ 20:07:
[...]


Shit ja dit was makkelijker geweest. Heb nu zelf een hokkiewokkie-implementatie gemaakt.
Als die niet goed werkt (kan maandag pas weer testen) dan ga dit gebruiken. Bedankt ervoor

Als jij nu al zegt een "hokkiewokkie-implementatie" gemaakt te hebben zou ik je toch willen adviseren met quartz oid te gaan beginnen en het andere dus weg gooien.. Anders is het "hacken"(als in om allerlei dingen heen coderen ipv het fatsoenlijk aanpakken) wat je aan het doen bent en niet programmeren..

[Red devil]

Bl4ckviper schreef op vrijdag 18 september 2009 @ 22:07:
[...]
Als jij nu al zegt een "hokkiewokkie-implementatie" gemaakt te hebben zou ik je toch willen adviseren met quartz oid te gaan beginnen en het andere dus weg gooien.. Anders is het "hacken"(als in om allerlei dingen heen coderen ipv het fatsoenlijk aanpakken) wat je aan het doen bent en niet programmeren..

Ha, als mijn "hokkiewokkie" implementatie goed werkt dan werk ik daar geen seconde meer aan . Heb nog wel 10 andere dingen te doen. Maar goed, zo hokkiewokkie is het nou ook weer niet, gewoon gebruik makend van de Timer class van Java met daarbij een extra check die met met System.getCurrentMillisec even checked of de voortgang nog wel in sync is.

[momania]

Nick_S schreef op vrijdag 18 september 2009 @ 15:30:
Je kan ook eens kijken naar Quartz. Hiermee kun je een timer aanmaken, welke elke x tijdeenheid een event afvuurt / methode aanroept. Dan hoef je zelf niet te gaan rommelen met tijd bijhouden.

Dat kan ook gewoon met de java.util.Timer hoor

Quartz bied in de situatie van de TS echt niets extra.

[Red devil]

momania schreef op vrijdag 18 september 2009 @ 22:26:
[...]

Dat kan ook gewoon met de java.util.Timer hoor

Quartz bied in de situatie van de TS echt niets extra.

Oh, want die Timer van java heeft, voor lange projecten, gigantische afwijkingen (ipv 8 ineens 13 uur enzo).

[momania]

Red devil schreef op zaterdag 19 september 2009 @ 09:19:
[...]


Oh, want die Timer van java heeft, voor lange projecten, gigantische afwijkingen (ipv 8 ineens 13 uur enzo).

Dat heeft niets met de timer zelf te maken, maar zoals oisyn ook al zei de manier waarop je 'm gebruikt. Door te switchen naar Quartz gaat dat echt niet ineens veranderen

[terje7601]

is dit niet gewoon een kwestie van

Java:

timer.schedule(...)

te vervangen door

Java:

timer.scheduleAtFixedRate(...)

?

[Chaos101]

Ik ben geen Java expert, maar een andere mogelijkheid is om telkens de systeemtijd op te vragen. deze loopt vrij correct. je kunt om de zoveel (milli)seconden controleren hoe laat het is, en dus hoe ver je al gescrolled moet hebben. Op deze manier heb je dus ook garantie dat het werkt, aangezien de klok van je OS redelijk precies de tijd bijhoudt.
zelfs als je actie een keer vertraagd wordt uitgevoerd, kun je precies uitrekenen waar je al had moeten zijn.

[Red devil]

terje7601 schreef op maandag 21 september 2009 @ 19:06:
is dit niet gewoon een kwestie van

Java:

timer.schedule(...)

te vervangen door

Java:

timer.scheduleAtFixedRate(...)

?

Zou kunnen, klinkt iig hoopvol.

Chaos101 schreef op maandag 21 september 2009 @ 20:01:
Ik ben geen Java expert, maar een andere mogelijkheid is om telkens de systeemtijd op te vragen. deze loopt vrij correct. je kunt om de zoveel (milli)seconden controleren hoe laat het is, en dus hoe ver je al gescrolled moet hebben. Op deze manier heb je dus ook garantie dat het werkt, aangezien de klok van je OS redelijk
precies de tijd bijhoudt.
zelfs als je actie een keer vertraagd wordt uitgevoerd, kun je precies uitrekenen waar je al had moeten zijn.

Klopt, deze methode heb ik nu maar gebruikt om de boel te synchroniseren, hierdoor loopt het wel. Misschien dat ik morgen nog even die scheduleAtFixedRate methode ga testen maar an sich werkt het wel goed nu!

[Nick_S]

Chaos101 schreef op maandag 21 september 2009 @ 20:01:
Ik ben geen Java expert, maar een andere mogelijkheid is om telkens de systeemtijd op te vragen. deze loopt vrij correct. je kunt om de zoveel (milli)seconden controleren hoe laat het is, en dus hoe ver je al gescrolled moet hebben. Op deze manier heb je dus ook garantie dat het werkt, aangezien de klok van je OS redelijk precies de tijd bijhoudt.
zelfs als je actie een keer vertraagd wordt uitgevoerd, kun je precies uitrekenen waar je al had moeten zijn.

En wat jij beschrijft is waarschijnlijk precies wat de Timer class voor je doet (of hij lost het op een andere manier op, maar dat maakt me niet uit) En dat maakt voor mij het verschil tussen een beginnend programmeur en een gevorderde programmeur. De taal kennen is 1, de bijbehorende API (of 3rd party API's) kennen is 2. Je wilt een scheiding aanbrengen in business logica (wat moet er gebeuren) en in applicatie logica (hoe gebeurt het). Voor het tweede is vaak al een library in de Java API of 3rd party API. Deze hebben het grote voordeel dat ze getest zijn en dat er al vaker van gebruik gemaakt is. Als je dit zelf wil gaan maken doe je dubbel werk, wat waarschijnlijk van mindere kwaliteit is.

En de stap naar vergevorderde programmeur: weten wanneer je de API links moet laten liggen en het toch zelf maken, omdat de API niet voldoet, bijv. geheugengebruik, ander algoritme, etc. Maar dit moet je wel erg goed kunnen beargumenteren. Zeggen dat je niet wist dat het al in een andere API zat, zet je meteen weer in categorie 1.

[.oisyn]

Sorry hoor, maar een API niet kennen maakt je nog geen beginnend programmeur. Het maakt je hoogstens een beginner met die specifieke API.

[ Voor 6% gewijzigd door .oisyn op 21-09-2009 21:32 ]

[Stephan Oudmaijer]

Chaos101 schreef op maandag 21 september 2009 @ 20:01:
Ik ben geen Java expert, maar een andere mogelijkheid is om telkens de systeemtijd op te vragen. deze loopt vrij correct. je kunt om de zoveel (milli)seconden controleren hoe laat het is, en dus hoe ver je al gescrolled moet hebben. Op deze manier heb je dus ook garantie dat het werkt, aangezien de klok van je OS redelijk precies de tijd bijhoudt.
zelfs als je actie een keer vertraagd wordt uitgevoerd, kun je precies uitrekenen waar je al had moeten zijn.

in principe wil je dit niet. opvragen van de systeemtijd is een relatief dure call.

ik zou ook eens naar jodatime kijken, dat echt een API om te werken met datum/tijd.

[Nick_S]

.oisyn schreef op maandag 21 september 2009 @ 21:31:
Sorry hoor, maar een API niet kennen maakt je nog geen beginnend programmeur. Het maakt je hoogstens een beginner met die specifieke API.

Ik zal hem even iets anders formuleren, hij was inderdaad een beetje kort door de bocht.

Ik vind een java programmeur die de JDK API niet kent een beginnend java programmeur.

[Haan]

En dan nog, wat boeit het of de TS een beginnend (Java) programmeur is of niet?

[.oisyn]

Stephan Oudmaijer schreef op maandag 21 september 2009 @ 21:35:
[...]


in principe wil je dit niet. opvragen van de systeemtijd is een relatief dure call.

Oh kom op, System.currentTimeMillis() doet er ongeveer 9ns over op mijn PC. Dat is *niets* (ongeveer 5 instructies bij een 2GHz CPU), en zeker niet gezien hoe vaak je 'm aan gaat roepen (1x per frame, en een frame duurt ongeveer 3.000.000 keer zo lang als die aanroep zelf bij 60 frames/s)

[ Voor 11% gewijzigd door .oisyn op 21-09-2009 21:57 ]

[momania]

Stephan Oudmaijer schreef op maandag 21 september 2009 @ 21:35:
[...]
ik zou ook eens naar jodatime kijken, dat echt een API om te werken met datum/tijd.

jodatime is alleen maar een date/time library, heeft niets met scheduling te maken.

[Nick_S]

Haan schreef op maandag 21 september 2009 @ 21:47:
En dan nog, wat boeit het of de TS een beginnend (Java) programmeur is of niet?

Niks, maar het ging mij om de tip om het zelf te gaan programmeren[*}, ipv. de API te gebruiken. Dat je geen 3rd party API's wil/kan gebruiken, kan ik nog inkomen, bijv. restricties vanuit school/licentie/etc. Maar dat je bestaande functionaliteit die je door de ingebakken API wordt geboden gaat herprogrammeren, is mijn inziens niet heel verstandig.

*Die kwam inderdaad van een niet-Java programmeur, dus het kan hem/haar niet verweten worden.

[Stephan Oudmaijer]

momania schreef op maandag 21 september 2009 @ 21:57:
[...]

jodatime is alleen maar een date/time library, heeft niets met scheduling te maken.

wel voor het berekenen van tijdsintervallen....

[momania]

Stephan Oudmaijer schreef op maandag 21 september 2009 @ 22:04:
[...]


wel voor het berekenen van tijdsintervallen....

Een hele library aanrukken om een simpele scheduling te doen en dan roepen dat je de systeem tijd niet op moet vragen, want dat is een dure call

[.oisyn]

Nick_S schreef op maandag 21 september 2009 @ 21:57:
[...]

Niks, maar het ging mij om de tip om het zelf te gaan programmeren[*}, ipv. de API te gebruiken. Dat je geen 3rd party API's wil/kan gebruiken, kan ik nog inkomen, bijv. restricties vanuit school/licentie/etc. Maar dat je bestaande functionaliteit die je door de ingebakken API wordt geboden gaat herprogrammeren, is mijn inziens niet heel verstandig.

*Die kwam inderdaad van een niet-Java programmeur, dus het kan hem/haar niet verweten worden.

Toch is de tip van Chaos101 geen slechte. Zelfs al zou je een stukje code periodiek laten aanroepen op vaste tijden, dan nog wil je je code tijdsafhankelijk maken (dus de scrollhoeveelheid laten afhangen van de huidige tijd) om op die manier eventuele schommelingen in de scheduling uit te cancelen. Een techniek waar vrijwel alle games gebruik van maken.

[ Voor 47% gewijzigd door .oisyn op 21-09-2009 22:14 ]

[Red devil]

Hehe wat cool, een hele discussie over mijn probleem.
Het klopt dat ik geen echte programmeur ben, van huize uit moleculair bioloog die tijdens aio tijd beetje java heeft geleerd. Dus veel aanpielen e.d.. De tip m.b.t. de SystemGetCurent etc werkt trouwens wel goed vooral i.c. de Timer module. Morgen zal ik de replies nog eens aandachtig doorlezen, zitten vast weer leerzame zaken tussen!

[Chaos101]

.oisyn schreef op maandag 21 september 2009 @ 22:12:
[...]


Toch is de tip van Chaos101 geen slechte. Zelfs al zou je een stukje code periodiek laten aanroepen op vaste tijden, dan nog wil je je code tijdsafhankelijk maken (dus de scrollhoeveelheid laten afhangen van de huidige tijd) om op die manier eventuele schommelingen in de scheduling uit te cancelen. Een techniek waar vrijwel alle games gebruik van maken.

Precies, en sommige games maken hier geen gebruik van(vermoed ik) zoals Supreme Commander, waar een seconde in het spel ongeveer 10 seconden voor de speler is als er echt veel units in het spel zijn. En dat is dus precies wat de TS wil voorkomen, dat er vertraging ontstaat, deze methode is daar dus juist perfect voor.

Een ietwat uitgebreidere manier is om om de X seconden de scrollsnelheid aan te passen, maar gewoon constant te scrollen. Je kunt dan af en toe corrigeren door de scrollsnelheid aan te passen. Als je dan bv. iedere 5 seconden zou corrigeren zou het heel soepel gaan en hoef je dus maar eens in de 5 seconden die 'dure' call aan te roepen, wat totaal geen significant verschil is voor dit programma.