W
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
