Re: System.Threading.Timers

Well, the good news is that each of the object that responds to a timer
should have on the order of 3-5 seconds before it needs to respond again.
It's just that the individual objects might respond 0.1 seconds apart).

Thanks, Chris.  Not to implement and test...

> -----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:31 AM
> To: [email protected]
> Subject: Re: [DOTNET-CX] 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®  http://www.develop.com

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