Re: System.Threading.Timers

BTW, when I say raise an event--in the context of the Timer class--that's
invoking the callback, not raising a .NET event (I've used it as a general
term).

On Mon, 5 Jun 2006 16:31:03 -0400, Peter Ritchie
<[email protected]> wrote:

>The only methods that start a timer: the System.Threading.Timer
>constructors...  The framework just creates a thread that calls SleepEx()
>with a calculated timeout.  When the SleepEx() call returns it checks to
>see what timer event(s) should be raised.  It calculates a single timeout
>based on when the next timer should raise, after the SleepEx() call it
>figures out which timer(s) should be raising in this timeframe and spawns
>worker thread(s) to raise the event(s).
>
>There is only one thread, not one per timer; it probably appeared in my
>last post with my comment "no more taxing" that it starts a thread per
>timer.  To be more clear, it would be less taxing than my post about
>starting one thread per action.
>
>On Mon, 5 Jun 2006 14:59:28 -0500, Ivanoff, Alex <[email protected]>
>wrote:
>
>>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 DevelopMentor®  http://www.develop.com

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