Re: System.Threading.Timers

What do you mean "simply starts up a thread and calls the Platform SleepEx"?
Which timer method does this?


-----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 14:24
To: [email protected]
Subject: Re: [DOTNET-CX] 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 DevelopMentorR  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