System.Timers.Timer Issue

[Matt]

I have a windows service that is using the timer object from
System.Timers to fire every minute and do some work. Occasionally
that work takes longer than a minute - and I don't want the elapsed
event to fire again if a previous event is still occurring.

In the elapsed event the first thing that I do is stop the timer.
Once the work is complete I start the timer again. My only concern is
that in the MSDN docs for this object it says that the timer object is
multithreaded and so if another thread has been spun off - calling the
stop event might not prevent reentrancy into the method.

The example code provided to keep this race condition from happening
is fairly complex (yes - I am "thread challenged") and was hoping that
there might be an easier way to see if the previous event is still in
motion, and if so keep the event from firing. I was going to use a
boolean value that gets set when execution begins and is reset when it
ends. It seems like a straightforward solution - I just wanted to get
some thoughts on it.

Any help or nudges in the right direction would be greatly
appreciated.

Thanks,

Matt Childs

 

[Matt]

It seems to me that you should not be using the timer with the AutoReset  
property set to "true" then.  Set that property to false, mark the current  
time when you enter your handler, and then only when you're done  
processing, calculate the actual next interval for the timer based on the  
time elapsed since you started processing.  If the time it took to do the  
processing is longer than your normal interval, then the new timer  
interval would just be 0 (i.e. the timer will fire immediately).

Alternatively, don't use a timer.  Just make a dedicated thread for the  
processing.  In that thread, sleep for the desired interval, calculating 
it as above.  IMHO this is probably more appropriate anyway.  Timers are  
great for things that are periodic and brief, but if you have a scenario  
where the execution of the work could be on the same magnitude as the  
duration of the timer, then you're not saving much in terms of thread  
overhead by using a timer.  In fact, you may be unnecessarily or  
excessively consuming a thread pool thread, depending on how long this  
processing actually takes.

Pete

Thanks Pete. I like the idea of turning off autoreset and just
resetting the timer when the job is done. There are only a couple of
times during the day when we might exceed our time interval - the rest
of the day the processing will complete well ahead of the interval.

I initially started to do this as a thread with a sleep at the end of
the processing - but that required sending the code into a loop -
which I cannot do in the Windows Service (at least the way I was
trying to do it). Essentially I was calling the loop from the OnStart
method of the service - but I ran into an issue where the service
controller at the OS level doesn't recognize that the service has
started - because essentially I have placed it into a loop and only
pausing or stopping the service can halt the loop. I later read in
the MSDN documentation that you can't place loops into the OnStart
call and to use timers - which is how I got to where I am today. Am I
missing something obvious?

Thanks again,

Matt