Charles,

All non main threads runs on the background, mostly with less priority than
a foreground thread.
A threading threading timer runs then even on its own thread like a
threading.dispatcher timer, quiet new, is the one in use with WPF.

Just my idea from what you wrote.

However, I did you not see give any response on my advice to use a
windows.timer.timer?

I simply don't understand why you don't want to use that?



Cor

"Charles" <blank@newsgroup> wrote in message
news:etyVHEQ#KHA.1888@newsgroup

> I'm going to attempt to answer this myself, as I've had an idea.
>
> Rather than try to generate a reliable timer tick, that won't get deferred
> when the system gets busy, how about generating a time-out instead. I can
> think of two obvious ways of doing it:
>
> 1. Put the timed task on it's own thread and go to sleep for the timer
> tick interval
> 2. Also on a separate thread, wait on a handle that never gets set, and
> set the timeout to the timer tick interval
>
> I don't know if both methods amount to the same thing, but I would be
> interested in people's opinions.
>
> In the first scenario, I spin up a dedicated thread on which I intend to
> perform my timed activity at a regular interval. I immediately put the
> thread to sleep for my elapsed time, wake up, perform my task and go back
> to sleep. This continues forever.
>
> In the second scenario, I create a ManualResetEvent and use WaitOne to
> wait for it to be signalled. I set the timeout to my elapsed time again.
> Each time the timeout expires I perform my task, and then go back to
> waiting again.
>
> In each case, does the technique behave differently from the way a timer
> works? In particular, do either or both of them avoid WM_TIMER events? Are
> either of these going to give me a more stable and reliable interval,
> bearing in mind that I don't mind the interval generated being +/-50%, but
> I don't want it to ever be +200%, for example?
>
> I have tried both, and as techniques they work, but testing in the case
> where the system is busy and the interval becomes extended is harder to
> test empirically.
>
> Charles
>
>
> "Charles" <blank@newsgroup> wrote in message
> news:uYYPRWC#KHA.4316@newsgroup

>> I asked a question related to this a little while ago, and thought that
>> I'd got my answer, but it has come back to bite me again.
>>
>> I currently use a System.Threading.Timer to generate a tick every 10
>> seconds. At each tick, I execute some code that will take a maximum of 5
>> seconds to complete. Most of the time, each subsequent tick occurs at
>> exactly 10 seconds after the previous one, but occasionally there can be
>> as much as 20 or 30 seconds between ticks.
>>
>> It was explained, in the previous thread, that the Threading timer relies
>> on WM_TIMER messages, which are low down on the priority list. If the
>> system gets a bit busy then these message seem to come further apart, so
>> my tick interval extends.
>>
>> What I need is a reliable way to generate a 10 second tick, that still
>> works when the system gets a bit busy. I'm running this on Windows Server
>> 2003 R2 x64, if that makes any difference.
>>
>> Does anyone have any ideas?
>>
>> TIA
>>
>> Charles
>>
>>

On 21-5-2010 18:16, Charles wrote:

> I'm going to attempt to answer this myself, as I've had an idea.
>
> Rather than try to generate a reliable timer tick, that won't get
> deferred when the system gets busy, how about generating a time-out
> instead. I can think of two obvious ways of doing it:
>
> 1. Put the timed task on it's own thread and go to sleep for the timer
> tick interval
> 2. Also on a separate thread, wait on a handle that never gets set, and
> set the timeout to the timer tick interval
>
> I don't know if both methods amount to the same thing, but I would be
> interested in people's opinions.
>
> In the first scenario, I spin up a dedicated thread on which I intend to
> perform my timed activity at a regular interval. I immediately put the
> thread to sleep for my elapsed time, wake up, perform my task and go
> back to sleep. This continues forever.
>
> In the second scenario, I create a ManualResetEvent and use WaitOne to
> wait for it to be signalled. I set the timeout to my elapsed time again.
> Each time the timeout expires I perform my task, and then go back to
> waiting again.
>
> In each case, does the technique behave differently from the way a timer
> works? In particular, do either or both of them avoid WM_TIMER events?
> Are either of these going to give me a more stable and reliable
> interval, bearing in mind that I don't mind the interval generated being
> +/-50%, but I don't want it to ever be +200%, for example?
>
> I have tried both, and as techniques they work, but testing in the case
> where the system is busy and the interval becomes extended is harder to
> test empirically.
>
> Charles
>

I'd say you'd be reinventing the wheel.

Unless you're doing *really* strange things, most (if not all) of the
out-of-the-box timers offer the funtionality you want. From what i've
gathered from the thread, you want a timer that's alerted *roughly*
(give or take *5* seconds) every 10 seconds.

Can you more clearly state what the actual problem is with those timers?

--
Willem van Rumpt

Hi Cor

Having read the article you posted the link to, I didn't read anything that
made me think the Timers.Timer was going to provide any real advantage over
the Threading.Timer, which I am currently using. Do they function
differently under the hood? I know it says that the System.Timers.Timer is a
wrapper around Win32 waitable timer objects, but it doesn't say exactly how
the Threading.Timer works.

It's not that I don't want to use it, just that I didn't see what I would
gain by switching.

Charles


"Cor Ligthert[MVP]" <Notmyfirstname@newsgroup> wrote in message
news:#VDv2JQ#KHA.3176@newsgroup

> Charles,
>
> All non main threads runs on the background, mostly with less priority
> than a foreground thread.
> A threading threading timer runs then even on its own thread like a
> threading.dispatcher timer, quiet new, is the one in use with WPF.
>
> Just my idea from what you wrote.
>
> However, I did you not see give any response on my advice to use a
> windows.timer.timer?
>
> I simply don't understand why you don't want to use that?
>
> Cor
>
> "Charles" <blank@newsgroup> wrote in message
> news:etyVHEQ#KHA.1888@newsgroup

>> I'm going to attempt to answer this myself, as I've had an idea.
>>
>> Rather than try to generate a reliable timer tick, that won't get
>> deferred when the system gets busy, how about generating a time-out
>> instead. I can think of two obvious ways of doing it:
>>
>> 1. Put the timed task on it's own thread and go to sleep for the timer
>> tick interval
>> 2. Also on a separate thread, wait on a handle that never gets set, and
>> set the timeout to the timer tick interval
>>
>> I don't know if both methods amount to the same thing, but I would be
>> interested in people's opinions.
>>
>> In the first scenario, I spin up a dedicated thread on which I intend to
>> perform my timed activity at a regular interval. I immediately put the
>> thread to sleep for my elapsed time, wake up, perform my task and go back
>> to sleep. This continues forever.
>>
>> In the second scenario, I create a ManualResetEvent and use WaitOne to
>> wait for it to be signalled. I set the timeout to my elapsed time again.
>> Each time the timeout expires I perform my task, and then go back to
>> waiting again.
>>
>> In each case, does the technique behave differently from the way a timer
>> works? In particular, do either or both of them avoid WM_TIMER events?
>> Are either of these going to give me a more stable and reliable interval,
>> bearing in mind that I don't mind the interval generated being +/-50%,
>> but I don't want it to ever be +200%, for example?
>>
>> I have tried both, and as techniques they work, but testing in the case
>> where the system is busy and the interval becomes extended is harder to
>> test empirically.
>>
>> Charles
>>
>>
>> "Charles" <blank@newsgroup> wrote in message
>> news:uYYPRWC#KHA.4316@newsgroup

>>> I asked a question related to this a little while ago, and thought that
>>> I'd got my answer, but it has come back to bite me again.
>>>
>>> I currently use a System.Threading.Timer to generate a tick every 10
>>> seconds. At each tick, I execute some code that will take a maximum of 5
>>> seconds to complete. Most of the time, each subsequent tick occurs at
>>> exactly 10 seconds after the previous one, but occasionally there can be
>>> as much as 20 or 30 seconds between ticks.
>>>
>>> It was explained, in the previous thread, that the Threading timer
>>> relies on WM_TIMER messages, which are low down on the priority list. If
>>> the system gets a bit busy then these message seem to come further
>>> apart, so my tick interval extends.
>>>
>>> What I need is a reliable way to generate a 10 second tick, that still
>>> works when the system gets a bit busy. I'm running this on Windows
>>> Server 2003 R2 x64, if that makes any difference.
>>>
>>> Does anyone have any ideas?
>>>
>>> TIA
>>>
>>> Charles
>>>
>>>

Hi Willem

The problem is simply that the Threading.Timer that I am using at present
doesn't always raise an event when the designated 10 seconds has expired. It
nearly always does, 99.9% of the time, probably. But occasionally, the event
is delayed for some reason, and might not occur for 20 or even 30 seconds
after the previous event. It is most likely to happen when the system is
quite busy (Windows Server 2003 R2 x64), perhaps performing a lot of disk
I/O, or something like that.

Charles


"Willem van Rumpt" <wdotvandotrumpt@newsgroup> wrote in message
news:OfGbYdQ#KHA.5916@newsgroup

> On 21-5-2010 18:16, Charles wrote:

>> I'm going to attempt to answer this myself, as I've had an idea.
>>
>> Rather than try to generate a reliable timer tick, that won't get
>> deferred when the system gets busy, how about generating a time-out
>> instead. I can think of two obvious ways of doing it:
>>
>> 1. Put the timed task on it's own thread and go to sleep for the timer
>> tick interval
>> 2. Also on a separate thread, wait on a handle that never gets set, and
>> set the timeout to the timer tick interval
>>
>> I don't know if both methods amount to the same thing, but I would be
>> interested in people's opinions.
>>
>> In the first scenario, I spin up a dedicated thread on which I intend to
>> perform my timed activity at a regular interval. I immediately put the
>> thread to sleep for my elapsed time, wake up, perform my task and go
>> back to sleep. This continues forever.
>>
>> In the second scenario, I create a ManualResetEvent and use WaitOne to
>> wait for it to be signalled. I set the timeout to my elapsed time again.
>> Each time the timeout expires I perform my task, and then go back to
>> waiting again.
>>
>> In each case, does the technique behave differently from the way a timer
>> works? In particular, do either or both of them avoid WM_TIMER events?
>> Are either of these going to give me a more stable and reliable
>> interval, bearing in mind that I don't mind the interval generated being
>> +/-50%, but I don't want it to ever be +200%, for example?
>>
>> I have tried both, and as techniques they work, but testing in the case
>> where the system is busy and the interval becomes extended is harder to
>> test empirically.
>>
>> Charles
>>

>
> I'd say you'd be reinventing the wheel.
>
> Unless you're doing *really* strange things, most (if not all) of the
> out-of-the-box timers offer the funtionality you want. From what i've
> gathered from the thread, you want a timer that's alerted *roughly* (give
> or take *5* seconds) every 10 seconds.
>
> Can you more clearly state what the actual problem is with those timers?
>
> --
> Willem van Rumpt

On 21-5-2010 19:20, Charles wrote:

> Hi Willem
>
> The problem is simply that the Threading.Timer that I am using at
> present doesn't always raise an event when the designated 10 seconds has
> expired. It nearly always does, 99.9% of the time, probably. But
> occasionally, the event is delayed for some reason, and might not occur
> for 20 or even 30 seconds after the previous event. It is most likely to
> happen when the system is quite busy (Windows Server 2003 R2 x64),
> perhaps performing a lot of disk I/O, or something like that.
>
> Charles
>

Ok, now I see where your idea of the second scenario comes from.

using a separate thread with a ManualResetEvent like this

private ManualResetEvent _quitEvent = new ManualResetEvent(false);
void ThreadProc()
{
while (!_quitEvent.WaitOne(timeout))
{
// ...Whatever it is your task should do...
}
}

will do the trick.

As soon as it's timeslice comes up, and the event is not signalled, the
thread will move into the while loop. Assuming it runs on it's own
thread, it will at least get scheduled and run (at some point).

The more interesting part though is why this wouldn't work with the
already provided timers. I haven't looked at the internals, but it seems
logical that the threaded timer also uses some waitable object to do
it's task. So the same problems may arise when using the scenario above.

Is there anyway, indication, or way of logging of *what* is going on
when the delay appears? Is the "delayed event" you talk about
synchronized (i.e. are the handlers called through Control.Invoke())
with the main thread?

--
Willem van Rumpt

Hi Willem

Yes, that's exactly what I was thinking, and almost exactly what I tried.

The process that runs when the interval has elapsed currently runs on the
thread of the callback; I'm using the Threading.Timer.

It's hard to be certain what is happening when the delay occurs. It used to
happen when memory was short (caused by a memory leak in BackupExec, but
that's been sorted now). The server where this happens I connect to using
Remote Desktop. I can often cause the problem if I transfer a file from a
mapped local drive over RDP to the server. That's about as much as I've been
able to tell. I'm tempted to give the manual reset event thing a try though,
now that you've picked up on the same idea.

Charles


"Willem van Rumpt" <wdotvandotrumpt@newsgroup> wrote in message
news:eq9vZLR#KHA.3628@newsgroup

> On 21-5-2010 19:20, Charles wrote:
>

>> Hi Willem
>>
>> The problem is simply that the Threading.Timer that I am using at
>> present doesn't always raise an event when the designated 10 seconds has
>> expired. It nearly always does, 99.9% of the time, probably. But
>> occasionally, the event is delayed for some reason, and might not occur
>> for 20 or even 30 seconds after the previous event. It is most likely to
>> happen when the system is quite busy (Windows Server 2003 R2 x64),
>> perhaps performing a lot of disk I/O, or something like that.
>>
>> Charles
>>

>
> Ok, now I see where your idea of the second scenario comes from.
>
> using a separate thread with a ManualResetEvent like this
>
> private ManualResetEvent _quitEvent = new ManualResetEvent(false);
> void ThreadProc()
> {
> while (!_quitEvent.WaitOne(timeout))
> {
> // ...Whatever it is your task should do...
> }
> }
>
> will do the trick.
>
> As soon as it's timeslice comes up, and the event is not signalled, the
> thread will move into the while loop. Assuming it runs on it's own thread,
> it will at least get scheduled and run (at some point).
>
> The more interesting part though is why this wouldn't work with the
> already provided timers. I haven't looked at the internals, but it seems
> logical that the threaded timer also uses some waitable object to do it's
> task. So the same problems may arise when using the scenario above.
>
> Is there anyway, indication, or way of logging of *what* is going on when
> the delay appears? Is the "delayed event" you talk about synchronized
> (i.e. are the handlers called through Control.Invoke()) with the main
> thread?
>
> --
> Willem van Rumpt

Thinking about it further, the downside of this approach is that the
interval between 'ticks' is not 10 seconds anymore. It is 10 seconds +
length of time task takes. Perhaps that's not the end of the world, but I
might have to factor that in somehow.

Charles


"Charles" <blank@newsgroup> wrote in message
news:#ATK1BU#KHA.3880@newsgroup

> Hi Willem
>
> Yes, that's exactly what I was thinking, and almost exactly what I tried.
>
> The process that runs when the interval has elapsed currently runs on the
> thread of the callback; I'm using the Threading.Timer.
>
> It's hard to be certain what is happening when the delay occurs. It used
> to happen when memory was short (caused by a memory leak in BackupExec,
> but that's been sorted now). The server where this happens I connect to
> using Remote Desktop. I can often cause the problem if I transfer a file
> from a mapped local drive over RDP to the server. That's about as much as
> I've been able to tell. I'm tempted to give the manual reset event thing a
> try though, now that you've picked up on the same idea.
>
> Charles
>
>
> "Willem van Rumpt" <wdotvandotrumpt@newsgroup> wrote in message
> news:eq9vZLR#KHA.3628@newsgroup

>> On 21-5-2010 19:20, Charles wrote:
>>

>>> Hi Willem
>>>
>>> The problem is simply that the Threading.Timer that I am using at
>>> present doesn't always raise an event when the designated 10 seconds has
>>> expired. It nearly always does, 99.9% of the time, probably. But
>>> occasionally, the event is delayed for some reason, and might not occur
>>> for 20 or even 30 seconds after the previous event. It is most likely to
>>> happen when the system is quite busy (Windows Server 2003 R2 x64),
>>> perhaps performing a lot of disk I/O, or something like that.
>>>
>>> Charles
>>>

>>
>> Ok, now I see where your idea of the second scenario comes from.
>>
>> using a separate thread with a ManualResetEvent like this
>>
>> private ManualResetEvent _quitEvent = new ManualResetEvent(false);
>> void ThreadProc()
>> {
>> while (!_quitEvent.WaitOne(timeout))
>> {
>> // ...Whatever it is your task should do...
>> }
>> }
>>
>> will do the trick.
>>
>> As soon as it's timeslice comes up, and the event is not signalled, the
>> thread will move into the while loop. Assuming it runs on it's own
>> thread, it will at least get scheduled and run (at some point).
>>
>> The more interesting part though is why this wouldn't work with the
>> already provided timers. I haven't looked at the internals, but it seems
>> logical that the threaded timer also uses some waitable object to do it's
>> task. So the same problems may arise when using the scenario above.
>>
>> Is there anyway, indication, or way of logging of *what* is going on when
>> the delay appears? Is the "delayed event" you talk about synchronized
>> (i.e. are the handlers called through Control.Invoke()) with the main
>> thread?
>>
>> --
>> Willem van Rumpt

>

It is hard for me to imagine a scenario where conventional timer messages
will be delayed sufficiently long enough to cause trouble with your
application. 5-10 seconds is a huge window. If you really are seeing such
a problem, the only thing that I can imagine is something that is seriously
wrong. This certainly isn't something that I've seen. Have you tried
System.Threading.Timer instead -- this create a threaded timer? If this
doesn't work, I think you need to look more closely at your system to see
where the hog resides.

--
Richard Grier, Consultant, Hard & Software 12962 West Louisiana Avenue
Lakewood, CO 80228 303-986-2179 (voice) Homepage: www.hardandsoftware.net
Author of Visual Basic Programmer's Guide to Serial Communications, 4th
Edition ISBN 1-890422-28-2 (391 pages) published July 2004, Revised July
2006.

Charles,

My aversion against the threading.timer is probably because of a bad
experience with that one,
However, there is another threading one.

I don't know if you can use that in your environment. My experience with
that one is fine.
http://msdn.microsoft.com/en-us/libr...chertimer.aspx

Cor

"Charles" <blank@newsgroup> wrote in message
news:u9ny##E#KHA.3628@newsgroup

> Hi Dick
>
> As I replied to Mike, 10 +/- 5 seconds would do me. I have to send a
> keep-alive message to another system approximately every 10 seconds. The
> other end will time-out after 25 seconds or so, which doesn't seem too
> tight a window, and yet sometimes the interval between ticks can be 30
> seconds or mor. I wondered about monitoring elapsed seconds, but it just
> seemed a bit kludgy. I can't imagine I'm the only person that does this
> sort of thing in Windows. How do other applications do it, I wonder, where
> they have to perform tasks at regular intervals, with a reasonable degree
> of accuracy?
>
> Charles
>
>
> "DickGrier" <dick_grierNOSPAM@newsgroup> wrote in message
> news:u4PzjnD#KHA.1888@newsgroup

>> As Mike said, Windows is not a real-time OS. Thus, you cannot guarantee
>> response.
>>
>> That said, you may be able to approach the accuracy that you desire. One
>> thing to realize is that resolution and accuracy are not the same thing.
>> And, since you will be writing code that is multi-threaded (and you have
>> only gross control of the various thread execution), and, in addition,
>> are executing in a non-deterministic OS, you have to careful what you ask
>> for -- and understand that you can never be absolutely certain that you
>> will get the precision that you seek.
>>
>> If you use a timer, you depend on multiple things, including the wm_timer
>> message. You might simply create a thread that monitors elapsed
>> milliseconds (example: Now.TimeOfDay.TotalMilliseconds). This will be
>> more accurate than the built-in timer. It will not, however, provide any
>> real determinism, so at the end of the day, you have to test it under
>> load and see if it meets your needs. If not... You may not be able to
>> get there from here.
>>
>> Dick
>> --
>> Richard Grier, Consultant, Hard & Software 12962 West Louisiana Avenue
>> Lakewood, CO 80228 303-986-2179 (voice) Homepage: www.hardandsoftware.net
>> Author of Visual Basic Programmer's Guide to Serial Communications, 4th
>> Edition ISBN 1-890422-28-2 (391 pages) published July 2004, Revised July
>> 2006.

>

Charles explained on 5/22/2010 :

> Thinking about it further, the downside of this approach is that the interval
> between 'ticks' is not 10 seconds anymore. It is 10 seconds + length of time
> task takes. Perhaps that's not the end of the world, but I might have to
> factor that in somehow.
>
> Charles
>
>

ThreadPool.QueueUserWorkItem

--
Tom Shelton