For a windows service, which is better, a wait-spin or a timer?

Question

This question about Timers for windows services got me thinking:

Say I have (and I do) a windows service thats waiting on a WaitHandle and when woken, it dives into a wait-spin like I have shown below in a flowchart

wait spin diagram http://www.86th.org/waitspin.jpg

I'm curious if using a timer would be better than a wait-spin loop (sometimes called a spin-wait). I'll be honest, I've never used timers for anything other than my own tinkering.

I don't have any plans to switch unless the differences are profound and the benefits of using a Timer are amazing. However, I'm very interested on peoples thoughts on one vs the other for future development of this project.

Let me know if this should be a wiki

Answer 1

I don't see you getting any benefit out of a timer. You are essentially behaving as a timer anyway with your sleep call, and you are not being a bandwidth hog since sleep yields up the time slice. Having an explicit timer wake up and call you is just going to complicate the code.

I wouldn't really say that you are doing a spin-wait, since I generally think of a spin-wait as something that doesn't sleep. It just burns all it's processor time waiting for the go signal.

Answer 2

Sleeping a thread and waiting on a handle with a timeout are basically the same thing under the covers. I would guess that timers are essentially implemented using sleep, so not much difference there, either. In other words, you could simplify your code by waiting on the handle with a timeout in a single loop and checking to see why the wait was released (data available or timeout), rather than implementing separate wait and sleep loops. Slightly more efficient than independent loops.

Ideally, you would not use sleep at all and simply depend on the data-generation code to correctly raise the event your consumption code is waiting on, with a longish timeout to handle when the event source has gone away.

If the data is external, such as on a socket or other input device, then the handle can generally be set to allow waiting for data to become available - no need to poll in that case since the event will always be signaled when data is ready for consumption.

Answer 3

We use threads. Not only do they perform like a timer, but they give us a handle to perform other operations while the thread is sleeping.

Answer 4

I think it really depends on your requirement:

1. Run the task every 5 min (for example, 12:00, 12:05, 12:10, ...)
2. Upon completing the current task, run the next task after 5 min.

Timer seems to be easy for the case 1 and Thread.Sleep seems to be easy for the case 2, even though Timer and Thread.Sleep can do both of them.

I , in fact, put a longer comment (including some consideration on the case 1) for a similar question (Windows service scheduled execution).

Answer 5

Polling is bad, and nearly always avoidable. Occasionally for trivial things it's less bad than the complexity needed to avoid it.

What source are you polling for "Has data?" that you can't turn into some kind of handle wait?

Also, don't Sleep() in serious code (like a service) for any significant amount of time. The only blocking you can do is WaitFor[Single|Multiple]Objects(...) where the list of handles includes an event that is fired when it's time to shut down the process. Find everywhere you're calling Sleep(millisec) and replace it with WaitForSingleObjects(g_shutdownEvent, millisec).

Answer 6

As Raymond Chen explains, "Yeah, whatever." If you can't figure out a way to get notified when your data is ready - then your SOL.