WaitableTimer versus TimerQueueTimer
-
hat jemand Erfahrung mit den beiden Windows-Timern und kann mir sagen wo die Unterschiede bzw. Vor- und Nachteile der beiden Timer-Arten sind.
Aus der Hilfe und den Beispielen werde ich jedenfalls nicht wirklich schlau.Gruß
Werner
-
Schau mal hier: http://www.codeproject.com/KB/system/timers_intro.aspx (sehr hilfreich)
Ich arbeite eigentlich immer mit Queue Timers und habe damit gute Erfahrungen gemacht.
Conclusion
What's the moral of the whole story?
When you decide that you need a timer in your application, choosing between the different timer variants should not be that hard. Follow these simple rules:
1. If you want your application to work on every 32 bit Windows platform, you do not need high precision, and the callback operation is fast enough not to disrupt the UI responsiveness, use a standard Win32 timer.
2. If you want your application to work on every 32 bit Windows platform, and you need high precision, use the multimedia timer.
3. If you want your application to work on Windows 98/NT4 and later, you need low system overhead, and can afford to block the calling thread, use the waitable timer.
4. If you want a high-precision, low-overhead, non-blocking timer that will work on Windows 2000 and later, use the queue timer.
-
Roger Wilco schrieb:
Schau mal hier: http://www.codeproject.com/KB/system/timers_intro.aspx (sehr hilfreich)
Danke Roger für die Antwort - das ist wirklich ein guter Link.
Es bleibt vor allem noch die Frage, ab wann man seine eigene TimerQueue anlegt und wie viele und welche Timer man dann da rein tut? oder anders gefragt, nach welchen Kriterien gehört ein zusätzlich hinzukommender Timer mit in eine vorhandene Queue hinein (inklusive der Systemqueue) und wann erzeugt man lieber eine neue?
Gruß
Werner
-
Werner Salomon schrieb:
Es bleibt vor allem noch die Frage, ab wann man seine eigene TimerQueue anlegt und wie viele und welche Timer man dann da rein tut? oder anders gefragt, nach welchen Kriterien gehört ein zusätzlich hinzukommender Timer mit in eine vorhandene Queue hinein (inklusive der Systemqueue) und wann erzeugt man lieber eine neue?
Das würde mich auch interessieren. Hat jemand eine Antwort?
-
Roger Wilco schrieb:
.. Hat jemand eine Antwort?
anscheinend nicht! Da das Thema aktuell bei mir wieder hochgekommen ist, kann ich inzwischen zumindest vermuten was die Antwort ist:
Beim Anlegen einer Timerqueue wird auch ein eigener Thread erzeugt. Wählt man beim Starten einen QueueTimers (CreateTimerQueueTimer) das Flag WT_EXECUTEINTIMERTHREAD, so werden die Callbacks des Timers auch in diesem Thread aufgerufen.D.h. in unserer Anwendung ist das so, dass ein Cluster von zusammenhängenden aber unterschiedlichen Objekten, in denen mehrere Timer unabhängig gestartet werden, alle durch ein gemeinsames Mutex geschützt werden. Es macht also keinen Sinn, wenn Objekte dieses Cluster von mehr als einen Thread via Callback aufgerufen werden. So gesehen ist das genau das, was wir brauchen.
Vielleicht kann noch jemand eine dieser Frage beantworten:
1.) Wenn man einen QueueTimer mit einer bestimmten Laufzeit startet (nicht zyklisch) und danach(!) einen zweiten QueueTimer in der gleichen TimerQueue aber mit einer längeren Zeit startet, kann man sich dann darauf verlassen, dass der erste Timer vor dem zweiten abläuft?
Wenn ja, wo ist sowas dokumentiert?
Bem.: bei den klassischen WindowsTimern ist das keineswegs so! Da hatten wir Programmfehler, die wir darauf zurückführen konnten , dass ein 5s-Timer, der nach einem 1s-Timer gestartet wurde, diesen überholte, also vorher auslief (genauer: vorher von WaitForMultipleObjects erkannt wurde)
- passiert, wenn die CPU unter Last steht.2.) Wenn man einen Timer neu parametrisiert (ChangeTimerQueueTimer) oder löscht (DeleteTimerQueueTimer), in wie weit ist dann garantiert, dass der Callback der vorherigen Einstellung nicht doch noch aufgerufen wird (racing condition)?
Gruß
Werner