Schleifenabbruch durch Esc Taste...

[BUG]

Eigendlich sollte kein Thread in der Lage sein, irgendeinen anderen durch eine Schleife zu "blockieren" (abgesehen von welchen mit niedriger Priorität). Dafür sorgt das Betriebssystem.
Deswegen finde ich auch die Lösung mit dem Sleep irgendwie merkwürdig (und die Erklärung dazu)

[himitsu]

Jeder Thread bekommt vom System ein "Fenster" von paar Millisekunden, in dem es einen Kern nutzen kann, bevor Windows den Kern für den nächsten Thread freimacht.
Mit einem Sleep(0) kann man sein "Fenster" sofort abbrechen ... damit Windows nicht "sinnlos" den Thread weiter behandelt, obwohl er "jetzt" nichts mehr machen will.


Was ist das denn für ein PC?
Wieviele Kerne gibt es und wie sind die ausgelastet? (während der Schleife und in den 12 Sekunden, bzw. davor/danach)
Wie sieht der RAM aus? (im Cache, Verfügbar, Frei, Ausgelagert und Zugesichert)

Bei einer 1-Kern-CPU kann man mit einem Thread ja problemlos alles lahmlegen. -> genausoviel/mehr Aufgaben (ala arbeitende Threads), als Arbeiter (Kerne)

[Codix32]

Zitat von himitsu:

...
Was ist das denn für ein PC?
Wieviele Kerne gibt es und wie sind die ausgelastet? (während der Schleife und in den 12 Sekunden, bzw. davor/danach)
Wie sieht der RAM aus? (im Cache, Verfügbar, Frei, Ausgelagert und Zugesichert)

Bei einer 1-Kern-CPU kann man mit einem Thread ja problemlos alles lahmlegen. -> genausoviel/mehr Aufgaben (ala arbeitende Threads), als Arbeiter (Kerne)

• Acer Predator G3610
  8 GB RAM
  64 Bit - Betriebssystem
  Prozessorkerne 4
  Grafik AMD Radeon HD 6870

Du wirst es vielleicht nicht glauben, aber wenn ich den Task Manager aufrufe und die Leistung anzeige, bleibt selbst die Grafik stehen, die sonst im Sekunden Rhythmus von rechts nach links läuft. Im Ressourcen Monitor werden gleich 8 Kerne angezeigt, obwohl die CPU bloß 4 Kerne hat ?!?
Im Ressourcenmonitor bleibt die Grafik nicht hängen und die Kerne 0, 2 und 4 schlagen aus.

Ups. Im 2. Versuch bleibr auch der Resourcenmonitor kurz stehen, zeigt dann aber Ausschläge bis fast 100% bei Kernen 2, 4 und 6 an.

[Dejan Vu]

Zitat von BUG:

Eigendlich sollte kein Thread in der Lage sein, irgendeinen anderen durch eine Schleife zu "blockieren" (abgesehen von welchen mit niedriger Priorität). Dafür sorgt das Betriebssystem.

Soweit ich mich erinnere, muss der Thread schon selber Bescheid geben, wenn er unterbrochen werden könnte, meist durch API-Aufrufe. Eine Endlosschleife ohne Sleep wird nie Bescheid geben, das jemand Anderes auch mal ran darf, zumindest ein Kern ist dann ausgelastet. Hier sollte jedoch ein Sleep(0) auch reichen. Immerhin könnte es ein, das Sleep(1) 18ms lang wartet, weiß ich jetzt aber nicht mehr so genau.

Zitat von himitsu:

Jeder Thread bekommt vom System ein "Fenster" von paar Millisekunden, in dem es einen Kern nutzen kann, bevor Windows den Kern für den nächsten Thread freimacht....Bei einer 1-Kern-CPU kann man mit einem Thread ja problemlos alles lahmlegen. -> genausoviel/mehr Aufgaben (ala arbeitende Threads), als Arbeiter (Kerne)

Wie passt das zusammen? Also entweder habe ich einen Scheduler, der per Interrupt den Thread unterbricht, dann kann ein Thread nix lahmlegen, oder ich habe einen Scheduler, der nur Prozesse unterbricht, aber keine Threads. Dann kann der Thread den Prozess lahmlegen.

Soweit ich weiß, unterbricht Windows die Threads nicht selbst, sondern nur die Prozesse...

[Dalai]

Wie ich schon schrieb, gibt es das Problem mit der Verzögerung auf den Abbruch bei mir auch nicht ohne Sleep. Ich hab das Sleep nur eingesetzt, um die sinnlose Auslastung der CPU zu unterbinden, weil die Schleife ohne Sleep eben so schnell durchrauscht, wie es die CPU hergibt. Mit Sleep wird die Schleife für einige Millisekunden unterbrochen und dann läuft die Schleife auch merklich langsamer durch. Ein Sleep(0) lastet übrigens genauso aus wie ohne Sleep.

Der Nebeneffekt des Sleep ist, dass auch andere Threads desselben Prozesses Zeit bekommen, auch wenn sie das aufgrund des Schedulers eigentlich sowieso müssten, vor allem bei Mehrkernern. Daher weiß ich nicht genau, warum das Sleep beim Verzögerungsproblem hilft. Ich vermute, dass der GUI-Thread derselbe ist wie der der Schleife - und da der mit der Schleife zu tun hat, kommt er nicht mehr zum Bearbeiten der GUI.

MfG Dalai

[Dejan Vu]

Ich meinte nur:
Sleep(0) - Threadwechsel
Sleep(1...9999) - Warten und Threadwechsel

Dann habe ich deine Intention von 'Sleep(1)' verstanden...

[BUG]

Zitat von Dejan Vu:

Soweit ich mich erinnere, muss der Thread schon selber Bescheid geben, wenn er unterbrochen werden könnte, meist durch API-Aufrufe.

Definitiv nicht. Sleep gibt den Prozessor freiwillig ab, blockierende Systemaufrufe auch. Ansonsten sind Threads präemptiv, dh. dem Thread wird die CPU entrissen wann immer das Betriebsystem Lust dazu hat.

Zitat von himitsu:

Dann kann der Thread den Prozess lahmlegen. [...] Soweit ich weiß, unterbricht Windows die Threads nicht selbst, sondern nur die Prozesse...

Man unterscheidet User-Level-Threads und System-Level-Threads. Von User-Level-Threads hat das System keine Ahnung und sie laufen nicht parallel. Unter Windows könnten das Fibers (sind eher Coroutinen) sein, man könnte es auch selbst implementieren. System-Level-Threads sind dem System bekannt und können echt parallel laufen. Die normalen Threads, die man in der Regel benutzt, sind System-Level-Threads.

Zitat von Dalai:

Ich vermute, dass der GUI-Thread derselbe ist wie der der Schleife - und da der mit der Schleife zu tun hat, kommt er nicht mehr zum Bearbeiten der GUI.

Ich auch ... schon weil das in einem Ereignishandler läuft, der vermutlich vom Mainthread aufgerufen wird. Dann sollte ProzessMessages aber ausreichen, da es der GUI nicht helfen sollte, wenn der Thread die Kontrolle abgibt.


Deswegen: Irgendwas läuft da verkehrt

[Blup]

Delphi-Quellcode:

{...}
Caption := inttostr(i);
{...}

Schon mal überlegt, was alles passiert, wenn die Caption eines Formulars geändert wird?
Da wird nicht nur ein Feld in der VCL-Klasse verändert.

[BUG]

Zitat von Blup:

Schon mal überlegt, was alles passiert, wenn die Caption eines Formulars geändert wird?

Stimmt, vermutlich wird da jedes mal eine Nachricht gesendet
Das könnte schon ein bisschen Ärger machen.

Zitat von Codix32:

Im Ressourcen Monitor werden gleich 8 Kerne angezeigt, obwohl die CPU bloß 4 Kerne hat ?!?

Wahrscheinlich Hyperthreading: Jeder echte Kern stellt 2 Hardware-Threads bereit. Die werden nicht echt gleichzeitig ausgeführt, können aber Wartezeiten im Prozessor überbrücken.

[Codix32]

Zitat von BUG:

Zitat von Blup:

Schon mal überlegt, was alles passiert, wenn die Caption eines Formulars geändert wird?

Stimmt, vermutlich wird da jedes mal eine Nachricht gesendet
Das könnte schon ein bisschen Ärger machen.

Zitat von Codix32:

Im Ressourcen Monitor werden gleich 8 Kerne angezeigt, obwohl die CPU bloß 4 Kerne hat ?!?

Wahrscheinlich Hyperthreading: Jeder echte Kern stellt 2 Hardware-Threads bereit. Die werden nicht echt gleichzeitig ausgeführt, können aber Wartezeiten im Prozessor überbrücken.

Wie kann ich das prüfen, ob es das Form1.caption ist?
Wenn ich das Caption auskommentiere läuft die Schleife zu schnell ab. Vielleicht eine zweite Schleife rein? Mal sehen.