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
I simply don't understand why you don't want to use that?
"Charles" <blank@newsgroup> wrote in message
> 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" <blank@newsgroup> wrote in message
>> 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?