Re: System.Threading.Timers

Yeah (especially if the event handling takes longer than the timer
resolution), you will need to either:

A) use either multiple timers and spread the objects across them
B) handle the timer event by checking if work needs to be done, and if
it does, use another thread (newly spun, or from a pool) to do the
actual work (allowing the timer thread to inform another object of the
timer event)


> -----Original Message-----
> From: Discussion relating to the specifics of the C# and 
> Managed C++ languages [mailto:[email protected]] 
> On Behalf Of Peter Osucha
> Sent: 05 June 2006 15:15
> To: [email protected]
> Subject: Re: [DOTNET-CX] System.Threading.Timers
> 
> I did think of this method, Chris, but I might need as much 
> as 0.1s resolution on the timer.  I guess if the timer is 
> running on its own thread, I could probably still use this 
> (better) solution...
> 
> 
> > -----Original Message-----
> > From: Discussion relating to the specifics of the C# and 
> Managed C++ 
> > languages [mailto:[email protected]]
> > On Behalf Of Chris Anderson
> > Sent: Monday, June 05, 2006 10:10 AM
> > To: [email protected]
> > Subject: Re: [DOTNET-CX] System.Threading.Timers
> >
> > FWIW you could have a single timer that ticks away every 
> second [1], 
> > and have all the objects subscribe to it's fire event.
> > They can then just check the time to see if they should do 
> anything or 
> > simply return.
> >
> > Then, instead of passing in the argument that says whether 
> an internal 
> > timer should be used, you can simply pass in a reference to an 
> > existing timer.
> >
> > Just a thought
> >
> > Chris
> >
> > [1] or more or less, depending on how often your timers fire
> >
> > > -----Original Message-----
> > > From: Discussion relating to the specifics of the C# and
> > Managed C++
> > > languages [mailto:[email protected]]
> > > On Behalf Of Peter Osucha
> > > Sent: 05 June 2006 15:01
> > > To: [email protected]
> > > Subject: [DOTNET-CX] System.Threading.Timers
> > >
> > > I have collection of objects (MyObj) - maybe up to 32 of them
> > > - that all need to independently 'wait' for an elapsed 
> time before 
> > > doing something once a method is called on them.  So I have been 
> > > reviewing what looks like the best option - Timer objects 
> from the 
> > > System.Threading.Timers namespace.
> > > What I am wondering is - what kind of impact having so 
> many active 
> > > timers might have on my machine, application?
> > >
> > > When the MyObj objects are created, one argument passed to the 
> > > constructor tells the object whether it will be using an internal 
> > > timer so I do have the capability to not automatically
> > create a timer
> > > with each MyObj - still, I wonder about having so many
> > timers objects
> > > around...
> > >
> > > Peter
> 
> ===================================
> This list is hosted by DevelopMentor(r)  http://www.develop.com
> 
> View archives and manage your subscription(s) at 
> http://discuss.develop.com
> 
> 
> 

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com