[alg] Polling m.b.v. aparte thread; waitable timer objecten

[Tomatoman]

Ik heb een testapplicatie gebouwd die gegevens van een data-acquititieapparaat uitleest. Via dat apparaat kan ik de status van een aantal motoren uitlezen en de motoren ook aan- en uitschakelen. Om met het externe apparaat te communiceren heb ik inmiddels een stuk software geschreven (Delphi 7) en dat werkt prima. Aangezien het apparaat geen hardwarematige triggers heeft die de software een seintje kunnen geven, moet de software de status van het apparaat regelmatig controleren (polling). Zodra de motoren in een bepaalde positie komen, moet de software de motoren uitschakelen.

So far so good. Maar wat nou als de computer zó druk bezig is dat de software een tijdje geen processortijd krijgt? In het ergste geval wordt dan niet snel genoeg gereageerd op de motorpositie en worden de motoren te laat uitgeschakeld. Dat wil ik ondervangen door de polling procedure in een aparte thread te stoppen die een hoge thread priority krijgt. Zelfs als de computer dan heel druk is reageert de software nog op tijd.

Tot dusverre heb ik heel eenvoudig een timer gebruikt die met regelmatige tussenpozen (20 milliseconden) het sein geeft om de status van de motoren op te vragen. Nu ik een aparte thread ga maken, zou ik de timer in de thread moeten plaatsen. Helaas is een timer (die Delphi creërt met de Windows API functie InitializeTimer) niet erg betrouwbaar als het op snelheid aankomt, mede doordat hij werkt met messages. Daarom wil ik van de ‘standaard’ timer af.

Nu overweeg ik de hele thread telkens even te bevriezen met een waitable timer object (InitializeWaitableTimer en gerelateerde API calls). Zodra de thread ontwaakt, checkt hij de status van de motoren en wordt door de waitable timer weer even bevroren. Ik hoop hiermee de kans dat de thread te laat reageert terug te brengen tot bijna nul. Ik heb echter geen ervaring met waitable timers. Is het een goed idee om het timer interval in te stellen op 10 milliseconden of iets dergelijks? Dat zou betekenen dat de thread telkens voor 10 milliseconden wordt bevroren en daarna weer ontwaakt. Geeft dat geen problemen met de systeemperformance?

[martijn_brinkers]

klinkt als een goede oplossing. Windows is geen 'Real Time Operating System' dus zal d'r geen garantie zijn dat er ook binnen een bepaalde tijd een context switch zal plaatsvinden. In de praktijk zal het echter wel meevallen, zeker als je de thread the allerhoogste prio geeft. Je moet er dan wel voor zorgen dat de code die wordt uitgevoerd zo snel mogelijk is zodat je niet je hele OS 'hangt'.

[madwizard]

Kun je geen multimedia timers gebruiken? Die zijn volgens mij ook wel vrij nauwkeurig gezien de mogelijke toepassing die de platform SDK noemt:

About Multimedia Timers

Multimedia timer services allow applications to schedule timer events with the greatest resolution (or accuracy) possible for the hardware platform. These multimedia timer services allow you to schedule timer events at a higher resolution than other timer services.

These timer services are useful for applications that demand high-resolution timing. For example, a MIDI sequencer requires a high-resolution timer because it must maintain the pace of MIDI events within a resolution of 1 millisecond.

...

[Tomatoman]

madwizard schreef op 18 maart 2004 @ 22:02:
Kun je geen multimedia timers gebruiken? Die zijn volgens mij ook wel vrij nauwkeurig gezien de mogelijke toepassing die de platform SDK noemt:

[...]

Die zijn nieuw voor mij. Dat wordt huiswerk voor morgen