Re: System.Threading.Timers

Actually, System.Threading.Timer (as opposed to
System.Widnows.Forms.Timer, which is a system-wide, limited resource) is
actually implement as a thread in .NET.  System.Threading.Timer simply
starts up a thread and calls the Platform SleepEx function to cause the
thread to sleep for x number of milliseconds.

So, it would appear using System.Threading.Timer is no more taxing than
starting a background thread as I outlined previously.

On Mon, 5 Jun 2006 14:08:44 -0400, Peter Osucha
<[email protected]> wrote:

>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