Timer verhalten bei hoher CPU Last / Funktionsweise

[Medium]

1. Der Timer verschiebt sich in diesem Fall nicht, nein. Die Ungenauigkeit ist immer gleich, egal wie hoch das Intervall ist. (Es kummuliert sich nur auf, wenn man ein kleines Intervall hat und darüber selbst einen Zähler führt der Echtzeitnah sein soll, weil diese Ungenauigkeit dann ja bei jedem Callback neu dazu kommt.)

2. Timer sind ein Service von Windows. Wie sie exakt intern funktionieren weiss ich nicht, aber ich vermute dass es kaum über plumpes "polling" der Systemzeit geht.

3. Du kannst ruhigen Gewissens das Intervall exakt einstellen, du musst nur zusehen dass dein Programm die Messageloop auch entsprechend abarbeitet; siehe 4

4. Das Ereignis wird gefeuert. Wen ich mich nicht irre haben Timer relativ hohe Priorität. Das Problem ist dann die Anwendung selbst, die die Message empfängt. Ist diese beschäftigt und arbeitet ihre Messageloop nicht ab, wird das Event verzögert. Es tritt aber ein.
Das sollte so lange wahr sein, wie nicht ein anderes Programm mit einer Priorität von TimeCritical nebenher die CPU vollknattert - das gehört sich allerdings auch nicht, und dürfte in freier Wildbahn kaum anzutreffen sein. Bzw. die Message könnte evtl. sogar raus gehen, nur wird dein Programm, wie sehr es auch versucht, nicht dazu kommen seine Msgloop zu verarbeiten.


Edit: Luckie, ich lese da auch gerade "low-priority message". Ist das nun nur im Rahmen der Messages zu verstehen, sprich andere Mesages haben Vorrang, aber Messages generell sind über Anwendungsprogrammen angesiedelt, oder ist das direkt in die Reiher der Prioritätsklassen wie für Threads im Allgemeinen zu verstehen? Ich war bislang immer der Auffassung, dass Messages immer hohe Prio haben, und lediglich der Empfänger der langsamere Teil ist der u.U. zu beschäftigt ist.