Need design for calling a method at regular intervals

[barker7]

In our app, we need to collect data at regular intervals (4, 8 or 16
seconds - user settable). The collection happens in a background
thread. My first approach was to do the collection, which takes about
0.5 seconds, then calculate how much time to sleep until the next
collection.

The problem is that when I cancel the collection, I have to wait for it
to emerge from the sleep before it actually exits. I could call
thread.Abort, but that seems frowned up.

A second approach is to have the collection loop wait for an event.
The event could be signalled from a Threading.Timer object or from the
user request.

Can I have your opinion on either of these approaches, or any othe
suggestions?

Thanks

Mitch

[Peter Bromberg [C# MVP]]

Not sure if I really understand what the issue is here. Why can't you just
call your collection method from within a timer's elapsed event handler? If
you need to cancel the operation, just set the timer to disabled, and
re-enable it on demand.
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"ba*****@yahoo.com" wrote:

In our app, we need to collect data at regular intervals (4, 8 or 16
seconds - user settable). The collection happens in a background
thread. My first approach was to do the collection, which takes about
0.5 seconds, then calculate how much time to sleep until the next
collection.

The problem is that when I cancel the collection, I have to wait for it
to emerge from the sleep before it actually exits. I could call
thread.Abort, but that seems frowned up.

A second approach is to have the collection loop wait for an event.
The event could be signalled from a Threading.Timer object or from the
user request.

Can I have your opinion on either of these approaches, or any othe
suggestions?

Thanks

Mitch

[Tom Spink]

ba*****@yahoo.com wrote:

In our app, we need to collect data at regular intervals (4, 8 or 16
seconds - user settable). The collection happens in a background
thread. My first approach was to do the collection, which takes about
0.5 seconds, then calculate how much time to sleep until the next
collection.

The problem is that when I cancel the collection, I have to wait for it
to emerge from the sleep before it actually exits. I could call
thread.Abort, but that seems frowned up.

A second approach is to have the collection loop wait for an event.
The event could be signalled from a Threading.Timer object or from the
user request.

Can I have your opinion on either of these approaches, or any othe
suggestions?

Thanks

Mitch

Hi Mitch,

You seem to have the basis for a good idea in your post; i.e. using a
signalled event. If you take a look at the AutoResetEvent class, part of
the System.Threading namespace, then you'll find it contains a Wait method.

The wait method blocks the calling thread, until it timesout, via the
timeout parameter, or until the AutoResetEvent is signalled, using the Set
method.

--
Hope this helps,
Tom Spink

Google first, ask later.

[Brian Gideon]

Mitch,

In addition to what Tom said the WaitOne method returns a bool
indicating why it returned. It will return true when the event is
signalled or false when the wait timesout. That will give you enough
information to determine whether you need to collect more data (because
of a timeout) or cancel the operation (because the event was
signalled).

If you need more complex event signalling then you can create multiple
WaitHandle object (either ARE or MRE) and use the WaitHandle.WaitAny
method which will block on an array of WaitHandle objects and return
the index of the event that was signalled.

Brian

Tom Spink wrote:

Hi Mitch,

You seem to have the basis for a good idea in your post; i.e. using a
signalled event. If you take a look at the AutoResetEvent class, part of
the System.Threading namespace, then you'll find it contains a Wait method.

The wait method blocks the calling thread, until it timesout, via the
timeout parameter, or until the AutoResetEvent is signalled, using the Set
method.

--
Hope this helps,
Tom Spink

Google first, ask later.

[Tom Spink]

Brian Gideon wrote:

Mitch,

In addition to what Tom said the WaitOne method returns a bool
indicating why it returned. It will return true when the event is
signalled or false when the wait timesout. That will give you enough
information to determine whether you need to collect more data (because
of a timeout) or cancel the operation (because the event was
signalled).

If you need more complex event signalling then you can create multiple
WaitHandle object (either ARE or MRE) and use the WaitHandle.WaitAny
method which will block on an array of WaitHandle objects and return
the index of the event that was signalled.

Brian

Tom Spink wrote:

>Hi Mitch,

You seem to have the basis for a good idea in your post; i.e. using a
signalled event. If you take a look at the AutoResetEvent class, part of
the System.Threading namespace, then you'll find it contains a Wait
method.

The wait method blocks the calling thread, until it timesout, via the
timeout parameter, or until the AutoResetEvent is signalled, using the
Set method.

--
Hope this helps,
Tom Spink

Google first, ask later.

Ah man, I knew I forgot to mention something! Cheers for that Brian!

--
Hope this helps,
Tom Spink

Google first, ask later.