Re: System.Threading.Timers

Are we talking about System.Threading.Timer class? With Change() methods?
This class internally uses private TimerBase class which is not much more
than a bunch of MethodImplOptions.InternalCall methods.

-----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 15:31
To: [email protected]
Subject: Re: [DOTNET-CX] 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 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