4

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

Community
  • 1
  • 1
Allen Rice
  • 19,068
  • 14
  • 83
  • 115

6 Answers6

5

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.

Christopher
  • 8,815
  • 2
  • 32
  • 41
  • Yeah I dont see much of a benefit either but I was curious. Also, I thought the "wait" in spin-wait or wait-spin implied that you where "waiting" in the form of Thread.Sleep(...). – Allen Rice Jul 08 '09 at 17:46
  • 1
    (edited) Usually, spin-wait means the code is in a continuous tight loop checking some value, chewing up all the CPU. This can be faster in some cases, such as on a multi-core system, if the wait is small AND contention is generally low (few threads competing for the resource). Search for InitializeCriticalSectionAndSpinCount, and SetCriticalSectionSpinCount. Note that the spin count is ignored on uniprocessor systems, since spin-wait will give you no benefit there: the current thread must be switched to the thread holding the lock before the lock can be released. – James Hugard Jul 08 '09 at 18:35
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.

James Hugard
  • 3,232
  • 1
  • 25
  • 36
  • Sorry, you might be confused by my addition of the wait handle in there. I'm actually comparing the wait-spin with the timer since both wait x milliseconds and then do something. The wait handle doesnt enter into the equation, I probably could have omitted that I even use it, sorry – Allen Rice Jul 08 '09 at 17:56
  • In that case, I don't think you'll see much difference either way. But, it sounds like maybe the whole solution could be handled differently to get you overlapped processing. Can you describe more about what the larger problem is? – James Hugard Jul 08 '09 at 18:09
1

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.

Jim Evans
  • 6,285
  • 10
  • 37
  • 60
1

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).

Community
  • 1
  • 1
Chansik Im
  • 1,473
  • 8
  • 13
1

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).

Marsh Ray
  • 2,827
  • 21
  • 20
  • Oh believe me, I know its not the best to poll but we did pretty good for the requirements that we were given. Long long long story short, we send a request for data to a 3rd party data provider and they reply to the request with an ACK. Later (2 to 28800 seconds later, no I'm not joking), they open up a NEW connection to our central aggregator with the data we asked for. Past that, it gets a little screwy because our client side app is hosted within a firewall that cannot be connected to from our aggregator, instead it has to go out and get the data from our own aggregator itself – Allen Rice Jul 30 '09 at 23:38
  • Lol. Seen that movie before. One possibility might be to have the client park a request at the aggregator, which blocks there until the data becomes available (or a long timeout). This allows the client to get the result as soon as it's available without hammering your aggregator with new polling requests. – Marsh Ray Jul 31 '09 at 00:16
0

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.

Mark Brackett
  • 84,552
  • 17
  • 108
  • 152