Timers - Which to choose?

  • Thread starter Thread starter Chris Marsh
  • Start date Start date
C

Chris Marsh

All

I have a MonitorClient class, which will control a number of monitor classes
implementing an IMonitor interface. These monitor classes will monitor
various different things on a server. Each monitor class will have a
differently timed cycle on which to perform its probing.

My question is: which Timer class woudl it be better to use within the
monitor classes - System.Threading.Timer, or System.Timers.Timer? I've read
up on both, but cannot really see which suits my requirements better. Both
seem to use a new worker thread from the CLR thread pool on which to raise
their events, so I cannot immediately see a benefit to using one or the other
for my particular scenario.

Any advice very much appreciated.

Cheers!
 
All

I have a MonitorClient class, which will control a number of monitor classes
implementing an IMonitor interface. These monitor classes will monitor
various different things on a server. Each monitor class will have a
differently timed cycle on which to perform its probing.

My question is: which Timer class woudl it be better to use within the
monitor classes - System.Threading.Timer, or System.Timers.Timer? I've read
up on both, but cannot really see which suits my requirements better. Both
seem to use a new worker thread from the CLR thread pool on which to raise
their events, so I cannot immediately see a benefit to using one or the other
for my particular scenario.
Click to expand...

The only difference between the two I'm aware of is that Timers.Timer
is a component (and thus can be manupulated with the visual designer),
and that it has SynchronizationObject property. The latter technically
allows it to raise events on some specific thread, rather than on a
new threadpool thread. If you do not need either of those, then you'll
probably want to stick with Threading.Timer.
 
Pavel

[..]

Pavel Minaev said:
The only difference between the two I'm aware of is that Timers.Timer
is a component (and thus can be manupulated with the visual designer),
and that it has SynchronizationObject property. The latter technically
allows it to raise events on some specific thread, rather than on a
new threadpool thread. If you do not need either of those, then you'll
probably want to stick with Threading.Timer.
Click to expand...

Thanks a lot for the information - I'll stick with System.Timers.Timer in
that case.

Cheers!
 
Another broken promise ::::::::::::sigh:::::::::::::::::::

Whoah is me :(

...

Just joking, hope you got it worked out.




Chris Marsh said:
sloan

Many thanks for the link - I'll follow up on it this evening.

Cheers!
Click to expand...
 
sloan

sloan said:
Another broken promise ::::::::::::sigh:::::::::::::::::::

Whoah is me :(
Click to expand...

Not at all, I really appreciate you taking the time to identify resources
for me.
Just joking, hope you got it worked out.
Click to expand...

I did, thank you. I used System.Timers.Timer on the grounds that I could
find no reason *not* to, and although System.Threading.Timers looked more
interesting I could not justify the work time to figure out how it worked :-)
One for the weekend, methinks...

Thanks again!
 
Back
Top