Race between WdfTimerStart and WdfTimerStop.

Question

Hi, 
My driver has a WDF timer object. The EvtTimerFunc of the timer object calls WdfTimerStart after it finishes processing whatever it needs to. 
Now, i have another thread which calls WdfTimerStop with the wait parameter set to TRUE. 
What happens in the following two scenarios ?
Scenario 1:
EvtTimerFunc: Gets swapped out. 
Other Thread: Calls WdfTimerStop(timer, TRUE); goes into wait state ?
EvtTimerFunc: wakes up, calls WdfTimerStart again. 
In this case will the timer start up again ? Will WdfTimerStop returns as soon as the EvtTimerFunc returns despite having called WdfTimerStart ?
Scenario 2: 
EvtTimerFunc: does what it needs to, calls WdfTimerStart and has still not completed.
Other Thread: Calls WdfTimerStop(timer, TRUE);
EvtTimerFunc: Completes/Returns.
Will WdfTimerStop return only after another EvtTimerFunc call back is executed ?
I assume such use cases are common and the simplest solution would be to check on some sort of flag before restarting the timer in the EvtTimerFunc call back.
Any help appreciated.
Thanks.
-R___K

Answer 1

Forgot about github!
These new opensource times. yep. Use the source.
It looks like the framework will not allow the timer call back function to restart the timer if WdfStopTimer has been called with the wait flag set to TRUE.
They have a kind of "pattern" there, known as rundown (or rundown protection?). It marks a thing as stopping and waits until it has actually stopped. While in the stopping state, attempts to add new work to it will be denied. After the rundown
on the thing ends, it may be reused again.
This is what Doron answered you for (1): after rundown for stop() completes, start() will work again.
-- pa