System.Threading.Timer period erratic

  • Thread starter Thread starter Oxns
  • Start date Start date
O

Oxns

Hi,

I have a system with a number of system.threading.timers. These are set to
fire every (say 200 milliseconds). If the thread has little work to do, the
timer fires again at the correct time BUT if the thread does a lot of work,
the next firing is delayed by some xx milliseconds.

Is there something in the timer code which prevents the timer period from
being reset until the delegate finishes ???. If so what is the best way
around this problem as I need timers to fire accurately at their specified
intervals.

NB I am using a system.diagnostics stopwatch to log the timer timings - so
could this also be an issue ???.

Thanks

Regards

Graham
 
You shouldn't have to reset the timers, unless the Interval changes. Just
set the AutoReset property to true.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.
 
| Hi,
|
| I have a system with a number of system.threading.timers. These are set to
| fire every (say 200 milliseconds). If the thread has little work to do,
the
| timer fires again at the correct time BUT if the thread does a lot of
work,
| the next firing is delayed by some xx milliseconds.
|
| Is there something in the timer code which prevents the timer period from
| being reset until the delegate finishes ???. If so what is the best way
| around this problem as I need timers to fire accurately at their specified
| intervals.
|
| NB I am using a system.diagnostics stopwatch to log the timer timings - so
| could this also be an issue ???.
|
| Thanks
|
| Regards
|
| Graham
|
|


Windows is not a real-time OS, so there is no guarantee that the event will
fire at the exact interval you specified, another thread in the system may
run at a higher priority currently blocking delivery of timer events to your
application. When that happens the event will be delayed, the event may even
get lost especially when using short intervals like 200 msec.

Willy.
 
Willy,

Thanks for the reply - I understand the limitations of Windows - in fact I
am seriously considering an embedded hardware solution with a REAL RTOS
(Forth) for this application ;-)).

I still would however expect the timer period to remain accurate, even if
some ticks start late (as they were blocked), I would expect these to
recover, but the effects appear to be cumulative :-(( - when one is delayed
the next also appears to be delayed - hence my question about when the timer
tick actually gets reset.

I'm also used to embedded systems for many years and would always ensure
that the first thing an interrupt handler often does is to reset its source.

Thanks agin though.

Graham
 
Back
Top