Re: System.Threading.Timers

Thanks for the comments, Peter.  However, I'm not sure how well they will
work in my actual situation.  All these timer 'events' are for process
control applications - opening and closing valves, actuating relays, etc..
Now when I say 0.1s resolution, I really just want to be 'pretty close' to
0.1s.  SO the way this usually works is in the application which has access
to these 8 (or 16 or 24 or 32) objects, a timed sequence (which is usually
repeated) needs to occur.  MyObj '1' might open and close a valve every 3
seconds for hours at a time whereas MyObj '27' might open and close a relay
at essentially random (meaning depending on other process measurements)
intervals (22.3s, 59.4 s, 3.7s) - and the same for other 'active' of the 8,
16, 24, 32 objects.

One good thing is that these 8, 16, 24, 32 objects are held in a collection
class and one 'manager' object always has access to the collection of
objects.  That means, that doing something like Chris suggests - perhaps
letting the 'manager' class have a timer that fires events every 0.1 seconds
allowing any 'listening' objects to decide if they need to respond sounds
reasonable.

For any people writing process control code, what other 'secrets' are there
to helping ensure good and accurate timing (besides offloading the control
to a PLC or some other device)?

Peter


> -----Original Message-----
> From: Discussion relating to the specifics of the C# and
> Managed C++ languages [mailto:[email protected]]
> On Behalf Of Peter Ritchie
> Sent: Monday, June 05, 2006 1:49 PM
> To: [email protected]
> Subject: Re: [DOTNET-CX] System.Threading.Timers
>
> Timers are generally a very limited system-wide resource,
> meaning they are apt to fail creation much sooner than other
> resources and their allocation is influenced by other applications.
>
> I would tend to want to avoid using them, especially if I
> need more than one or two.
>
> If I needed to be able to have up to 32 distinct actions that
> need to be performed with a given period I would tend to use
> background threads and a WaitHandle.  Keep in mind, even with
> timers, you're not going to have exact resolution.  You have
> a specific resolution by which you can set your period; but
> there's no guarantee they'll get raised in that same
> resolution (e.g. if the processor is bogged down an added
> delay will most likely occur).
>
> Anyhow, I would start up one thread per action (or object)
> and use WaitHandle.WaitOne(Int32, Boolean) to get the thread
> to sleep for a given amount of time to simulate the period.
> e.g. in your ThreadStart method, or your background worker
> event handler:
> AutoResetEvent autoEvent = new AutoResetEvent(false);
> autoResetEvent.WaitOne(6010, false); // sleep for 60.1 seconds
>
> This is just an example, in reality you don't want to halt a
> thread strictly on one handle and a large time frame such as
> this.  You'll want your thread to be cancel-able.  So, you'll
> probably want to wait on at least two objects so you can
> cancel each thread arbitrarily and not have your application
> stuck in memory upon exit waiting for all your threads to
> timeout.  You'll probably also want a bit of code to take
> into account processing time (between two WaitOne() calls) to
> get a more accurate period.
>
> On Mon, 5 Jun 2006 13:13:16 -0400, Peter Osucha
> <[email protected]> wrote:
>
> >Yes, Peter, I had intended to have them run their own
> threads - which
> >doesn't seem like the best idea.
> >
> >Peter
> >
> >> -----Original Message-----
> >> From: Discussion relating to the specifics of the C# and
> Managed C++
> >> languages [mailto:[email protected]]
> >> On Behalf Of Peter Ritchie
> >> Sent: Monday, June 05, 2006 11:43 AM
> >> To: [email protected]
> >> Subject: Re: [DOTNET-CX] System.Threading.Timers
> >>
> >> By "indpendently 'wait'" do you mean they're running their own
> >> threads?
> >>
> >> On Mon, 5 Jun 2006 09:56:53 -0400, Peter Osucha
> >> <[email protected]> wrote:
> >>
> >> >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...

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

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