Re: System.Threading.Timers

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