Ich habe eine ganz mysteriöse Erscheinung, und vielleicht weiß jemand Rat?

Folgende Situation:
Habe eine Applikation (EXE) geschrieben (müsste ich mal als Demo reinstellen). Darin befindet sich einiger Code aber auch ein Panel, auf dem sich eine OpenGL Szene darstellt. Das Rendern wird mit Events ausgelößt, also: Panel.Paint, Panel.Resize, Panel.MouseDown, Panel.MouseUp. Der OpenGL Code ist in ein OGLObject gemacht.
Weiter gibt es einen separaten Thread, in den Daten simuliert werden (enthält kein OpenGL). Die simulierten Daten werden in ein Record abgelegt. Zur Erklärung: Zum Beispiel fährt ein Auto durch die Szene, die Position des Autos wird in dem Thread errechnet.
In meiner EXE werden im Idle Event der Record des Threads nach einen Record im OGLObject kopiert und ein Render ausgelößt. Damit fährt das Auto durch die Szene.
Soweit zur Technik. Funktioniert auch alles ganz Prima und flüssig.

Nun zum Problem:
Der Thread läuft in einer Schleife mit einem Sleep(). Außen ist ein Schieber (TrackBar) mit dem ich den Thread Normalgeschwindigkeit Sleep(25) und Beschleunigung Sleep(1) laufen lassen kann. Die interne Simulation ist so ausgelegt, das sie 40ms braucht. Es sei gleich gesagt: + oder – 1 ms ist nicht wichtig!

Starte ich die EXE auf einigen PCs, läuft die Simulation immer langsam oder minimal beschleunigt ab. Messungen haben ergeben, das der Sleep entweder ca. 10 oder 15 oder 25 ms ausführt, auch wenn er auf 1 steht.
Starte ich jetzt z.B. Delphi (wohlgemerkt: Nur parallel starten!) führt der Sleep(1 bis 25) aus, so wie gewünscht??? Die selbe Erscheinung habe ich, wenn ich VisualStudio starte. Auch wenn ich das Windows Spiel PINBALL starte, habe ich diesen Effekt, aber nur wenn ein Ball gestartet ist und das Spiel im Vordergrund ist!
Interessant ist, bei einigen PC führt der Sleep(1 bis 25) immer aus, so wie gewünscht???

Für mich ist dieses Verhalten unerklärlich, da sich der Code ja nicht ändert! Hat jemand vielleicht eine Idee? Gibt es irgend ein Befehl um den Sleep Intervall einzustellen? Gibt es irgend ein Flag das gesetzt wird?

Ein normales Sleep ist viel zu ungenau. Der Timer hat nur eine Auflösung im Bereich von ca. 10-15 ms. Außerdem ist das ganze wie du gemerkt hast stark abhängig von anderen Prozessen und Threads. Du solltest nebenher die tatsächlich vergangene Zeit messen, z.B. mit einem Performance Counter. Dazu einfach mal nach QueryPerformanceCounter suchen. Entsprechend der gemessenen Zeit führst du dann deine Simulation durch.

Bei Physik-Simulationen ist es allerdings üblich diese unabhängig von der vergangenen Zeit in einem festen Intervall laufen zu lassen, sagen wir mit 60 fps. Dadurch erreichst du reproduzierbare Ergebnisse. In deinem Hintergrund berechnest du einfach solange Physik-Schritte (von 1/60 sec) bis du mit der gemessenen Zeit aufgeholt hast bzw. du um nicht mehr als einen Schritt überholt hast. Dann geht der Thread kurz schlafen.

(Gut bei 40ms für die Simulation ist 60 fps natürlich nicht machbar, aber 20fps vielleicht)

_________________
Yeah!

OK, sehe ich. Ist einen Versuch wert, werde mal probieren.

Aber warum geht es auf einigen PC's, oder mit extern getarteten Programmen?

Weil sich mehrere Anwendungen einen CPU-Kern teilen können...oder auch nicht. Zudem kann eine CPU etwa in einen Stromsparmodus schalten...etc, etc.

_________________
Yeah!

Habe selbst die Lösung gefunden:

Es ist immer das selbe, wenn du erst mal das Keywort kennst, kannst du fast alles Googeln...

Also: Windows setzt bei start den Sleep auf 10 ms (ungefähr, ist abhängig wie viele Applikationen laufen, wie der Time Slize ist u.s.w.). Bei Servern wird er sogar auf 15 ms gesetzt. Warum ich dann bei Sleep() Millisekunden angeben soll, ist nicht ganz klar?
Mit den Befehl TimeBeginPeriod(1) am start des Threads und mit TimeEndPeriod(1) am ende des Thread führt Sleep(1) ziemlich genau die Millisekunde aus. Die beiden Funktionen stammen aus der Multimedia Unit MMSystem und haben wohl etwas mit Video und Audio Zeittakt zu tun. Auf alle Fälle funktioniert es Prima.
Auch das Kuriosum ist leicht erklärt: Die beiden Funktionen setzen das Sleep Systemweit! Wenn ich also eine andere Applikation starte, die diese Befehle benutzt (z.B. Delphi macht es!!!), läuft auch meine Applikation im Millisekunden Takt!!

Alles Klar..... so einfach kann es sein ...

Das ist ja scheiße! Du müsstest also dein Sleep immer direkt dafor neu kalibrieren. Und selbst das reicht nicht, wenn eine andere Anwendung reinshedulled wird, dann kann es die genauigkeit wieder ändern und dein Code läuft nicht mehr wie erwartet....
Keine gute Technologie.
Ich würde zu nem anderen Timer raten.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Im MSDN findet man recht schnell, dass sleep mit einem 16ms Intervall arbeitet, dies liegt daran, dass das OS die magischen 16ms für alle Sleep,prozesswechsel und ähnliches verwendet. Das hat was mit der abwärts Kompatibilität mit sehr sehr alten Windows zu tun. Es ist aber nicht schlimm, da man ja diese Zeit selber per API ändern kann. Allerdings ist sleep Böse, dieses nutzt man eigentlich nur, wenn man sich davor fürchtet, dass im Prozessmanager 100% auslastung steht. Alternativ und oft besser ist ein yield, welches ledeglich das OS ansagt, wenn wer was zu tun hat kann er, sonnst mach ich weiter.
Das ist das gleiche verhalten wie der Leerlauf Prozess, der läuft solange auf volllast, bis ein prozess was zu tun hat.

Unter Linux ist usleep wesentlich feinfühliger, dagegen ist selbst ein 1ms sleep von windows ein Elefant im Porzellanladen. Die haben halt von anfang an ein high performance counter für alles genutzt und entsprechend auch die Auflösung im microsekunden Bereich.

Also zusammen gefasst, windows sleep ist böse, man kann es aber durch windows api auf 1ms reduzieren, linux hat nicht solche probs aber egal welches sleep beide sind wenn möglich gegen yield aus zu wechseln.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Ist ja ganz schön, dass es unter Linux solche Probleme nicht gibt. Aber was nützt diese Information jemandem der unter Windows programmiert? Nicht so wirklich viel behaupte ich mal. Und vielleicht gibt es ja auch Fälle in denen es Sinn macht, dass die Anwendung nicht sinnloserweise 100% CPU Last erzeugt. Es soll auch zunehmend Notebookbesitzer geben habe ich mir sagen lassen. Abgesehen davon ist Busy Waiting wohl auch in 98% der Fälle nicht unbedingt der beste Stil. Mit anderen Worten nicht jeder Fall lässt sich über genau einen Kamm scheren. Manchmal muss man einfach mal aus seinem Gebiet (über seinen Tellerrand) schauen...

MASU: Sleep hat unter anderem auch immer das "Problem", dass du dadurch die Kontrolle an den Task Sheduler von Windows übergibst. Wenn also etwas anderes im System (sei es dein Rendern auf einem SingleCore) gerade der Meinung ist es benötigt mehr Zeit als du, dann kann sich die Zeit von Sleep auch deutlich vergrößern. Darauf hast du keinen Einfluss mehr. Ich weiß da auch nicht ob deine Herangehensweise an dieses Problem so ideal ist. Selbst mit 1ms Timer kannst du immer solche Probleme haben. Von daher ist es nahezu immer ausgeschlossen, dass du zu einem definierten Zeitpunkt eine Benachrichtigung bekommst.

Daher denke ich das du zwar mir sleep deinen Thread schlafen legen kannst aber auf der anderen Seite immer messen müsstest wie lange er jetzt wirklich geschlafen hat und das in deine Berechnungen mit einfließen zu lassen und Schwankungen ausgleichen zu können. Stichwort Timebased Movement. Selbst wenn du mit Threads arbeitest kommst du da wohl nicht herum.

Ich kann in deinem Fall auch nicht abschätzen ob es nicht noch sinnvollere Möglichkeiten gibt. Wenn du zum Beispiel Arbeit in einen Thread auslagern willst würden sich auch 2x TEvent anbieten. Dann würde der Thread so lange schlafen bis neue Arbeit anliegt. Das wäre wesentlich sinnvoller als es immer zu pollen.

Was mich auch etwas irritiert sind die 40ms Arbeit innerhalb des Threads. Also wenn das keine Schleife ist die 40ms wartet dann würde ich sagen, dass die Zeit für die Arbeit je nach System durchaus auch deutlich variieren kann und du so nicht genau sagen kannst, dass es auch wirklich nur 40 ms sind.

Eine Garantie dafür, dass ein Sleep() wirklich exakt ist und der Thread nach genau der Anzahl an Millisekunden, die angegeben wurde, wieder Rechenzeit bekommt, kann ein Scheduler gar nicht geben. Denn es kann immer sein, dass ein anderer Thread (oder mehrere davon) nunmal so viel Rechenzeit in Anspruch nehmen, dass nichts mehr übrig ist. Das einzige, was ein Betriebssystem garantieren kann, ist dass der Thread frühestens nach einer bestimmten Zeit wieder Rechnzeit bekommt. Mag sein, dass das alle wissen, aber ich wollte es nur mal klarstellen.

Ich stelle mir die Arbeit eines Schedulers so vor (ist aber bloß eine Vermutung ):
Er hat eine Liste von den Threads, die gerade im Sleep-Status sind und eine von denen, die gerade Rechenleistung brauchen. Dazu einen Zeitwert, wann das nächste mal ein schlafender Thread geweckt werden will.
Jetzt geht der Scheduler die "wachen" Threads der Reihe nach durch und weist ihnen für sehr kurze Zeit (< 1 ms) eine CPU zu. Wenn der gerade laufende Thread dabei ein Sleep() aufruft, kommt er sofort in die Schlafenliste. Wenn der Scheduler alle "wachen" Threads einmal durchlaufen hat, prüft er, ob die nächste Aufwach-Zeit schon erreicht ist. Falls ja, sucht er den schlafenden Thread, der wach werden will und aktualisiert den Wert für die nächste Aufwachzeit. Dann geht das ganze von vorne los, es sei denn, in der Liste mit den "wachen" Threads ist kein Eintrag. Dann kann der Scheduler dem Prozessor nämlich sagen, dass dieser heruntertakten darf.
Unterschiedliche Prioritäten ließen sich realisieren, indem man entweder die Zeitspanne, in der ein Thread an einem Stück rechnen darf variiert, oder indem nicht jeden Thread in jeder Runde drankommen lässt.

Da verstehst du was falsch. Ob du ein Mobile, PC oder Notebook hast macht kein Unterschied. Die Geräte haben ein gewisses CPU Kontingent und bei mobilen Geräten wird dies OnDemand getaktet. Sobald kein Prozess mehr CPU-Zeit braucht geht die restliche CPU-Zeit an den Leerlaufprozess. Dieser ist kein Prozess der die CPU sinnfrei rödeln lässt sondern nur dazu dient, um die CPU-Zeit und Prozesslast zu erkennen(um den Sheduler mit sinnvollen Daten zu füttern).
Wenn dein Prozess mit yield ständig die Regie ab gibt, dann geht er in andere Prozesse und im idealfall in Leerlauf. Was dazu führt, das dein System nicht hoch taktet und den Akku unnötig belastet. Soviel die Theorie, in der Praxis spielt noch die Prozesspriorität und der Sheduler mit rein.
Wenn du ein Prozess startest, dann hat er höhere Prioritäten und sobald der Prozess Sheduler fest gestellt hat, das nix mehr zu tun ist geht er zurück zu deinem Thread und der macht dann ein loop und ruft wieder yield auf. Wenn also nix läuft läuft das loop auf der CPU und man hat ne menge unnutzer Auslastung aber eine verdammt hohe genauigkeit. Es gibt hier verschiedene Möglichkeiten.
1.) Bei Spielen will man eher kein Sleep sondern yield mit einem timeout(ab win7 und server 2003 weiß ich das es dies in windows gibt, sonnst gibs dirty workarounds, in linux hat das pthread immer dabei). Das yield gibt anderen Prozessen dann einfach kurze cpu zeiten, der timeout wird vorher berechnet, eventuell auch 0.
2.) Bei Mobile Apps sollte man immer auf signals, dma, push, interruptes also kurz das OS sagt dir wann du wieder arbeiten sollst(kleiner Tipp Windows messageloop ist nicht die einzige möglichkeit die messages zu bekommen, denn dies wäre ja poll und nicht push verfahren).
3.) Intervall based Apps wie z.B. cronjobs führt man in festen intervallen aus und diese kann man mit ner loop und sleep laufen lassen.
4.) Hybriden, man hat ne app die in keine Kategorie so wirklich passt und baut hybriden aus verschiedenen Techniken. So z.B. parallelisierung auf ein kurzen Bereich, DMA operationen danach, sleep/yieldloop zum schluss und oder andere Anreihungen und Kombinationen gehen auch.

Ein weiteres Problem tut sich bei den API's auf, Windows nutzt relative zeiten, wärend linux globale zeiten nutzt, also bei windows sagt man ich will in 5ms aufgewäckt werden, bei linux sagt man wäck mich bei now()+5ms auf. An sich sieht das nicht schlimm aus aber wenn wir nun schon so pingelig sind und um resolution von 1ms diskutieren, ist 2. akkurater, da der Task Sheduler definitv zu der Zeit wieder in den Prozess springen soll(sogar häufig kann, da er weiß wer wann wieder dran sein will und besser planen kann) und windows sleep nur sagt, warte mindestens so lange(und nur mit höherern Prozss Prioritäten als andere kann man sicher sein, dass windows nicht ungewollt noch andere prozesse durchläuft, statt wirklich nach 1ms zurück zu gehen). Letzlich bleibt zu sagen, will man weniger als eine ms warten, dann geht das nicht ohne auf die kosten von CPU Leistung unter Windows. Denn Windows sieht dies nicht vor und die besten Lösungen sind loops mit yield für dinge unter 1ms und über 1ms dann ein sleep wo vorher die resolution auf 1ms gesetzt wird.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Ich selbst Programiere recht Zeitkritisch bis zu 1mSek genau unter WinXP.
'Lasershowausgabe'

Dazu benutze ich die Kompenente TSVATimer.

lg Gento

Thomas mir ging es in dem von dir zitierten Abschitt darum, dass du dir durch das vorherige Post durchaus Überheblichkeit wenn nicht sogar auch Arroganz vorwerfen lassen könntest. Und da habe ich manchmal auch stark das Gefühl als ob du sehr vieles nur aus deiner Sicht betrachtet und nur die kann dann ja die einzig Richtige sein. Ich wollte es zwar eigentlich nicht so direkt sagen aber bitte.

Ein Sleep(0) übergibt die Kontrolle auch kurzzeitig wieder an den Sheduler. Wenn niemand was zu tun hat, dann bekommt das Programm auch sofort wieder die Kontrolle zurück. Das was du sagst ist ja nicht falsch. Nur hat die Sache einen Schönheitsfehler. In der Praxis wirst du es nicht hinbekommen, dass dein Thread auf der gleichen Priorität läuft wie der Leerlaufprozess. Entsprechen wird er immer bevorzugt. Ein Yield/Sleep(0) in einer Schleife ist nichts anderes als ein Busy-Waiting. Nur eines was anderen Threads die Leistung nicht versagt. Allerdings läuft die CPU dennoch im Dauerzustand. Ergo 100% Last auf dem Kern.

Wenn man aber sehr kleine Zeiten abpassen muss dann mag das okay sein. Wobei ich dann eher auch auf das Threadwechseln verzichten würde. Denn dadurch könnte es immer passieren, dass der Thread eben einige Millisekunden im Sheduler hängt. Nur Fälle in denen man so etwas machen muss sind in normalen Anwendungen und Spielen wohl eher nicht die Regel. Und wie ich oben schon geschrieben habe sollte man sich nie auf eine genaue Zeit blind verlassen. Wenn man sich allerdings darauf verlassen muss stellt sich mir die Frage ob mein Design so gut gewählt ist oder ob ich nicht vielleicht andere Möglichkeiten habe. Und die sind von Fall zu Fall unterschiedlich. Da kann man keine pauschale Aussage treffen.

1. 2. 3. 4.: Um das Abzukürzen. Man muss sich immer überlegen wofür man eine Anwendung schreibt und was man damit erreichen will. Und dabei ist es in der Programmierung wohl recht üblich, dass man ausgewählte Techniken entsprechend kombiniert. Keine Fall ist wie der Andere.

Linux: Ich weiß, dass Linux das bessere Sheduling hat. Aber was nützt einem die Erkenntniss nur unter Windows.

Yield gibt es auch mit timeout, wie ich schon geschrieben habe, um sicher zu gehen, dass er dann wieder da ist.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Das hatte ich gesehen. Auch wenn es im gesammten post eher nicht hervorsticht. Klingt doch aber auch deutlich angebrachter als
etc.