When the thread calling SetWaitableTimer terminates while another thread remains on the timer, is the timer canceled?

Question

http://msdn.microsoft.com/en-us/library/windows/desktop/ms686289%28v=vs.85%29.aspx

According to msdn, the comment sections say: "If the thread that sets the timer ends and there is an associated termination procedure, the timer is canceled. However, the state of the timer remains unchanged. If there is no termination procedure, then terminating the stream does not affect the timer. "

Then further down, it says: " If the thread calling SetWaitableTimer ends, the timer is canceled. This stops the timer before it can be set to the alarm state, and cancels the outstanding BTRs, does not change the signaling state of the timer. "

Therefore, my question is, if I have one thread calling SetWaitableTimer without an associated termination procedure, and another thread calling WaitOnMultipleObjects (passing in the timer object descriptor), and the thread that calls SetWaitiableTmer will exit soon after that, whether the timer object is canceled or will it still be signaled when the period expires?

Answer 1

The documentation is somewhat unclear. I think the best you can do is test it yourself. However, I believe that the timer is canceled automatically only if I / O completion is used.

I can give some “theoretical” background about APC windows to justify my (educated) assumptions.

APC = "asynchronous procedure call". In windows, each user-mode thread is equipped with the so-called APC queue, which is controlled by the system of the queue of procedures that should be called in this thread. A thread can enter the so-called "warning wait" (as intended), during which it can perform one or more procedures in this queue. You can either manually call the procedure call in the APC queue, or issue I / O, which, upon completion, will "put" the procedure call there.

In simple words, the scenario is as follows: you issue several I / O operations, and then you expect the completion (or failure) of any of them and, possibly, some other events. Then you call one of the waiting functions: SleepEx , WaitForMultipleObjectsEx or similar.

Important Note: This mechanism is designed to support single-threaded concurrency. That is, the same thread issues several I / O operations, waits for something, and responds accordingly. All APC procedures are guaranteed to be called on the same thread . Therefore - if this stream exits - there is no way to call them. Consequently, all outstanding I / O operations are also canceled .

There are several Windows API functions that work with asynchronous I / O, while they allow you to select several completion mechanisms (for example, ReadFileEx ): APC, setting an event, or completing an I / O port completion. If these functions are used with APC, they automatically cancel I / O if the output stream exits.

Therefore, I assume that the auto-save timer is canceled only when used with APC.

Answer 2

To provide more information directly from the implementation of pending timers: if you use CompletionRoutine, the timer is placed in a linked list associated with a stream called SetWaitableTimer. When the thread completes, the kernel scans the list associated with the dying thread and cancels the timers that are still queued.

If you do not use the termination routine, the timer is never added to any linked thread in the list and therefore is not canceled when any particular thread dies.