How to Generate an Accurate Timer Tick
in [Dot Net]
|
Prev: problem sending email from non-administrator account
Next: BUY SPANISH FAKE PASSPORT/FAKE SPANISH ID CARD SALE ONLINE/SWISS FALSE PASSPORT BUY/UK FAKE ID CARD
From: Charles on 21 May 2010 13:15 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(a)planet.nl> wrote in message news:#VDv2JQ#KHA.3176(a)TK2MSFTNGP05.phx.gbl... > 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(a)nowhere.com> wrote in message > news:etyVHEQ#KHA.1888(a)TK2MSFTNGP05.phx.gbl... >> 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(a)nowhere.com> wrote in message >> news:uYYPRWC#KHA.4316(a)TK2MSFTNGP04.phx.gbl... >>> 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 >>> >>>
From: Charles on 21 May 2010 13:20 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(a)skoutsoftdotcom> wrote in message news:OfGbYdQ#KHA.5916(a)TK2MSFTNGP04.phx.gbl... > 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
From: Willem van Rumpt on 21 May 2010 14:24 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
From: Charles on 21 May 2010 19:50 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(a)skoutsoftdotcom> wrote in message news:eq9vZLR#KHA.3628(a)TK2MSFTNGP04.phx.gbl... > 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
From: Charles on 22 May 2010 03:51
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(a)nowhere.com> wrote in message news:#ATK1BU#KHA.3880(a)TK2MSFTNGP04.phx.gbl... > 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(a)skoutsoftdotcom> wrote in message > news:eq9vZLR#KHA.3628(a)TK2MSFTNGP04.phx.gbl... >> 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 > |