469,923 Members | 1,627 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,923 developers. It's quick & easy.

Need design for calling a method at regular intervals

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

Oct 11 '06 #1
4 2302
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

Oct 11 '06 #2
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.
Oct 11 '06 #3
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.
Oct 11 '06 #4
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.
Oct 11 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Joh | last post: by
3 posts views Thread by Omer van Kloeten | last post: by
1 post views Thread by joe | last post: by
31 posts views Thread by cctv.star | last post: by
5 posts views Thread by bean330 | last post: by
10 posts views Thread by CuTe_Engineer | last post: by
reply views Thread by Waqarahmed | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.