Geek Answers Handbook

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

This question about timers for Windows services made me think:

Let's say I have (and I) a Windows service waiting for WaitHandle , and when it wakes up, it sinks into waiting, as I showed below in a flowchart

expectation waiting diagram http://www.86th.org/waitspin.jpg

I am wondering if using a timer would be better than a wait-spin cycle (sometimes called spin-wait). I will be honest, I never used timers for anything other than my own messing around.

I have no plans for switching unless the differences are deep and the benefits of using a timer are awesome. Nevertheless, I am very interested in the thoughts of peoples in relation to each other for the future development of this project.

Let me know if it will be a wiki

+4
source share
6 answers

I don’t see you getting any benefit from the timer. You, in fact, behave like a timer with your sleep challenge, and you are not a pig strip, as sleep leads to a reduction in time. Having an explicit timer wakes up and causes you to simply complicate the code.

In fact, I would not say that you are doing “waiting”, since I usually think of spin-waiting as that which does not sleep. It just burns all the processor time, waiting for the go signal.

+5
source

Sleeping flow and waiting on a handle with a timeout are basically the same under the covers. I would suggest that timers are essentially implemented through sleep, so there aren't many differences. In other words, you could simplify your code by waiting on the timeout descriptor in one loop and checking why the wait (available data or timeout) has been freed up, instead of doing separate wait and wait cycles. Slightly more efficient than independent circuits.

Ideally, you will not use sleep at all and simply envy the data generation code to correctly raise the event that your consumption code expects, with a long timeout for processing when the event source has left.

If the data is external, for example, on a socket or other input device, then you can usually set a descriptor so that you can expect the data to become available - there is no need to poll in this case, since the event will always be signaled when the data is ready for consumption.

+2
source

We use threads. They perform not only a timer, but also give us the opportunity to perform other operations while the thread is sleeping.

+1
source

I think this really depends on your requirement:

  • Run the task every 5 minutes (e.g. 12:00, 12:05, 12:10, ...)
  • After completing the current task, run the next task after 5 minutes.

The timer seems easy for case 1, and Thread.Sleep seems easy for case 2, although Timer and Thread.Sleep can both.

I essentially put a longer comment (including some consideration in case 1) for a similar question ( scheduled execution of a Windows service ).

+1
source

The survey is bad and can almost always be avoided. Sometimes for trivial things this is less harmful than the complexity necessary to avoid it.

What source did you interview for "Do you have data?" that you cannot turn into some kind of waiting pen?

Also, do not do Sleep() in serious code (such as a service) for any significant amount of time. The only lock you can do is WaitFor[Single|Multiple]Objects(...) , where the descriptor list includes an event that fires when the time comes to complete the process. Find wherever you call Sleep(millisec) and replace it with WaitForSingleObjects(g_shutdownEvent, millisec) .

+1
source

As Raymond Chen explains, "Yes, no matter what happens." If you cannot find a way to get notified when your data is ready - then your SOL.

0
source

More articles:


All Articles