Timers skipped

[Zeev Jabotinsky]

All 3 types of timers in managed code (Form, Threading and
Server) give us the following problem: they should fire a
message transmission on a serial line every 50 ms. They do
it until one does something such as clicking on the task
bar (even in an empty location) or clicking a form button.
When that happens, the timer may miss the next activation
of the elappsed timer method or the callback method
(depending on which type of timer is used) for as much as
300 ms. That is missing of six !!! cycles.
Can you refer us to a method that would receive the
highest priority so that we do not miss any timer driven
event. We can tolerate a few ms delay from time to time
but no more than half a cycle (25 ms).

[Michael Giagnocavo [MVP]]

If the transmission is of a near constant time, would having one thread with
a sleep cycle work?
-mike
MVP

"Zeev Jabotinsky" <ta...@netvision.net.il> wrote in message
news:079a01c38df7$62dc9e50$a101...@phx.gbl...

[Zeev Jabotinsky]

That does not work better than timers that trigger events.
Is there any way to receive kernel priorities for a timer
and fine tune it?

Zeev

>.
>

[Steve]

A timer isn't really designed to work in "real-time".
If real-time is important, .Net framework on
Windows NT probably isn't the optimal solution.
That said, 50ms is probably possible to achieve.

To the suggestion to have a separate thread you
wrote "That does not work better than timers that
trigger events.". Did you really try that? If
so, how? I would try something like this:

ThreadProc()
{
Thread.CurrentThread.Priority = Thread.ThreadPriority.AboveNormal;
while (...)
{
DoMyWork();
Thread.Sleep(50); // or maybe even 0 here
}
}

Having a thread sleeping and then doing work is
not the same thing as using timer threads from
the thread pool. I would expect a better result
with a separate thread.

"Zeev Jabotinsky" <anon...@discussions.microsoft.com> wrote

[Sean Wolfe]

I think the issue with this is that the DoMyWork() method could take x
amount of milliseconds to execute. So then when the thread sleeps for 50
milliseconds, it will be longer than 50 milliseconds to when the next time
DoMyWork() is called. This makes the loop also variable in time. Whereas a
Timer "Should" always fire an event every 50ms interval. But unfortunately
the .NET timers use the windows events system to make the timer
notifications happen. This is not very good for really low resolution
timers. 50 milliseconds should be actually doable on the System.Timers
Timer. But I've only used this very sparingly.

If you really need highly accurate, short period timers, it would be best to
look at windows Multimedia timers, but you'd have to write some unmanaged
code to access it.

Sean

"Steve" <nos...@nospam.com> wrote in message
news:Ouw4Trdl...@TK2MSFTNGP10.phx.gbl...

[Michael Giagnocavo [MVP]]

A possible workaround would be to have a loop that sleeps, and fires off
another thread each time, instead of performing the work on the same thread.
Sure, you can have overlapping workitems, but if it needs to be every 50ms,
regardless of work time, that works.

The other way would be to take the datetime when you wake up (using one
thread) and before sleeping, subtract to get a timespan and sleep the
remaining time. If the timespan is less than 0, then you've overworked, and
no sleep happens.

Setting the thread priority to realtime could help as well to ensure you get
scheduled.

-mike
MVP

"Sean Wolfe" <swolfe.N.0.$.p.A.^^@spindlex.N.0.$.p.A.^^.com> wrote in
message news:%23alIQd6...@TK2MSFTNGP10.phx.gbl...