Re: 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