Windows echtzeitfähig mit Delphi

[himitsu]

Du wirst immer Pausen bekommen, selbst wenn man die Thread- und Process-Priority extrem hochschraubt und "versucht" überall die Prozesse an bestimmte Kerne zu binden. (sowas machen diese Echzeitspezialisten raktisch und der Aufwand dafür ist nicht grade sehr gering, wenn das durchgängig und vorallem zuverlässig funktionieren soll)

Es gibt ja immer mehr Prozesse als CPU-Kerne, womit Windows deinen Prozess vermutlich immer mal wieder aus der CPU rauswirft, um andere Threads bearbeiten zu können. Damit wird dein Thread also immer mal wieder kurz schlafengelegt. (Windows schaltet das durchschnittlich so etwa alle 15-50 Millisekunden um)

Und Timer kannst'e eh vergessen denn der liebt numal aktuell bei einer Auflösung von etwa 15-16 Millisekunden -> siehe die vielen Threads zu GetTickCount und sessen Auflösung.
Abgesehn von gewissen Multimediatimern, welche oft auch über Threads getriggert werden.

[BUG]

Im Nanosekunden-Bereich werden selbst solche Sachen wie Cache-Misses interessant. Da wird es schon extrem eng.
Neben dem Scheduling können dir auch Interrupts den Spaß verderben, TLB-Misses, Paging ... im Prinzip alles was nicht dein Code ist.

Andererseits ... wenn du Aussetzer/Jitter verträgst und nicht gerade ein Atomkraftwerk an deiner Steuerung hängt: Ich würde es ausprobieren ... vielleicht genügt es dir ja.
"Echtzeit"-Priorität, alles andere auf einen anderen physischen Kern. In diesem "Echtzeit"-Thread läuft dann nur das absolut nötige und wenn du warten musst, dann wartest du halt aktiv.

[Namenloser]

Generell ist das mit „Echtzeit“ so eine Sache. Es hängt ja nicht nur am Scheduling, sondern auch so Dinge wie Speicherverwaltung, evtl. Swapping, und propabilistische Algorithmen (z.B. Quicksort) muss man berücksichtigen. Die ganze Laufzeitbibliothek muss echtzeitfähig sein. Die Delphi-RTL ist auf sowas aber nicht ausgelegt, und auch OpenGL dürfte damit kaum vereinbar sein.

Ich habe keine Erfahrung mit Echtzeitsystemen, aber ich denke, die einzige sichere Lösung wäre, den Echtzeit-Teil von der Oberfläche komplett physisch zu trennen. Also einen dedizierten Rechner/Platine (?), der sich nur um die Ansteuerung der Maschine kümmert und mit einem abgespeckten Echtzeit-Kernel (oder gleich ohne Betriebssystem) läuft, und einen getrennten Rechner mit Windows, auf dem die Benutzeroberfläche läuft. Die beiden Rechner kommunizieren dann über eine serielle Schnittstelle o.ä..