Timer Sicherheit?

Question

Hi,

ich will einen Timer nutzen der in Zyklen einen Code sendet.

Weil der Rechner enorm belastet wird können Zyklen nicht

exakt gesendet werden der Timer puffert dann die Meldungen,

das ist ein unerwünschter Effekt. Was kann ich tun, das der Timer

nicht puffert und genauer arbeitet auch bei extremer Systembelastung?

Ist Stopwatch die Lösung oder .. ?

Danke

Gruß Michael

 

Answer 1

Hallo Michael

es gibt in .NET etliche Timer
http://msdn.microsoft.com/en-us/magazine/cc164015.aspx

bei korrekter Anwendung sollte einer davon durchaus passen.
Stopwatch dient eher zur Zeitmessung.

Answer 2

P.S.

 > bei extremer Systembelastung

wenn wirklich die .NET-Runtime (inkl Thread-Pool) und das ganze _System_  (alle CPU-Cores?) über längere Zeit (~Sekunden) voll ausgelastet sind,
dann werden die Ausführungs-Timings immer schwierig einzuhalten, sowohl generell Win32-seitig wie managed-Code umso mehr.

Im einfachsten Fall muss man da die Timer-Events eher als 'Wakeup' verstehen, dann selber per Zeitvergleiche/Kalkulation das ('chronologische') Timing + korrekte Ablauflogik sicherstellen.

Andernfalls:
bis zu einem gewissen Grad könnte man da zB
mit hohen Thread- (plus Prozess-) -Prioritäten und einem sorgfältig geschriebenen ('schlanken') Worker-Thread arbeiten. Aber unter .NET hat alles irgendwo seine Grenzen  (zB wegen GC - wobei ggf aktueller .NET Versionen eher besser).
Im Extremfall und mit Multi-Core CPU könnte man dann auch noch mit der CPU-Affinity 'spielen'.

Answer 3

Hallo M.,

kein Timer kann unter Windows 100% gewährleisten, dass die gewünschten Aktion "genau" zu einem bestimmten Zeitpunkt ausgeführt wird.
Es kommt da auf den Anspruch an - quasi: wieviel Millisekunden sind für Dich akzeptabel. Ansonsten käme man auch in den Bereich der sogenannten "harten" und "weichen" Echtzeit.

Das Problem am Windows.Forms.Timer beispielsweise ist, dass er über das Win32 WM_TIMER Ereignis arbeitet und deswegen nur behandelt werden kann, wenn die MessageLoop abgearbeitet werden kann, was aber in vielen Implementationen oft nicht richtig berücksichtigt ist.
Eine simple while-Schleife im Main-Thread etwa verhindert dies ggf.!

[Microsoft .NET & C#: System.Windows.Forms.Timer vs System.Timers.Timer/System.Threading.Timer]
http://netpl.blogspot.com/2010/05/systemwindowsformstimer-vs.html

Du hast letztlich selbst unter Windows Forms ggf. mehr Chancen, Dein Vorhaben (in diesem Fall) zu bewerkstelligen, wenn Du den System.Timers.Timer benutzt, denn bei diesem Szenario startet das OS selber einen Thread bei jedem Tick.
Dennoch hast Du dann ggf. trotzdem das Problem, bei UI-Aktionen in den Main-Thread zu marshallen und musst auch da dann ggf. Blockaden berücksihtigen. Grundlegende Ansätze dafür etwa hier:

[Bearbeiten von Steuerelementen aus Threads]
http://dzaebel.net/ControlInvoke.htm

Stopwatch trifft das Thema hier überhaupt nicht, die Klasse ist zum Messen von Zeiten.

---

ciao Frank

Answer 4

    > Was kann ich tun,

Je nach Wiedereintrittsfähigkeit solltest Du auf jeden Fall den Tick-Handler selber eben "schnell" ausführen. Ggf. also nur die nötigsten Aktionen ausführen und andere längere Aktionen von einer eigenen Klasse handeln, die ggf. eine Queue benutzt. Hier auch Ansätze:

[SO WIRD'S GEMACHT: Synchronisieren eines Producer- und Consumerthreads (C#- und Visual Basic)]
http://msdn.microsoft.com/de-de/library/yy12yx1f.aspx

Es kommt jetzt etwas auf die Anforderungen und den realen Code an ...
Von höheren Thread- oder Prozess-Prioritäten würde ich abraten.

---

ciao Frank