Schleifenabbruch durch Esc Taste...

[himitsu]

Zitat:

Zitat von Dalai (Beitrag 1278854)

Übrigens wird nur ein Kern ausgelastet, nicht mehr - ist ja nur ein Thread und ein Thread kann gleichzeitig nur auf einem Kern laufen.

Da windows die Prozesse nicht an einen Kern bindet, und die sowieso ständig in und aus den Kernen schiebt (es gibt ja mehr Threads als Kerne), kann es passieren, daß Windows den Prozess auch in mehreren Kernen laufen lässt. Natürlich nicht gleichzeitig, sondern nacheinander, so daß in der Gesamtrechnung ein Thread dennoch nicht mehr als einen Thread auslastet.

PS: Drum bringt es auch wenig sich massig viele Kerne/CPUs zu besorgen, denn wenn es nicht genug Threads gibt, um alle Kerne auszulasten, verschwendet man nur Rechnenleistung.

[hathor]

Zitat:

Zitat von himitsu (Beitrag 1278989)

PS: Drum bringt es auch wenig sich massig viele Kerne/CPUs zu besorgen, denn wenn es nicht genug Threads gibt, um alle Kerne auszulasten, verschwendet man nur Rechnenleistung.

Du reihst Dich ein bei den Urhebern dummer Sprüche:
„Ich glaube, dass es auf der Welt einen Bedarf von vielleicht fünf Computern geben wird.“
http://de.wikipedia.org/wiki/Thomas_J._Watson

[himitsu]

16 Kerne für einen Office+Internet-PC sind also besser als 8?

[DeddyH]

Natürlich, wenn 15 Kerne vor sich hinschlummern statt nur 7, ist das doch viel cooler.

[Jumpy]

Zitat:

Zitat von DeddyH (Beitrag 1279015)

Natürlich, wenn 15 Kerne vor sich hinschlummern statt nur 7, ist das doch viel cooler.

Es sei denn es kommt zur Kernschmelze, dann ist es natürlich viel hotter. :-D

Tschuldijung, Freitag eben...

[Codix32]

Zitat:

Zitat von himitsu (Beitrag 1278989)

Zitat:

Zitat von Dalai (Beitrag 1278854)

Übrigens wird nur ein Kern ausgelastet, nicht mehr - ist ja nur ein Thread und ein Thread kann gleichzeitig nur auf einem Kern laufen.

Da windows die Prozesse nicht an einen Kern bindet, und die sowieso ständig in und aus den Kernen schiebt (es gibt ja mehr Threads als Kerne), kann es passieren, daß Windows den Prozess auch in mehreren Kernen laufen lässt. Natürlich nicht gleichzeitig, sondern nacheinander, so daß in der Gesamtrechnung ein Thread dennoch nicht mehr als einen Thread auslastet.

PS: Drum bringt es auch wenig sich massig viele Kerne/CPUs zu besorgen, denn wenn es nicht genug Threads gibt, um alle Kerne auszulasten, verschwendet man nur Rechnenleistung.

Ja ok, es laufen Prozesse, die man nochmal in Threads unterteilen kann, oder so ähnlich.
Aber die werden ja großteils blockiert, wenn ich die Schleife ohne Sleep laufen lasse.
Es geht dann eben 12 Sekunden lang nichts mehr. Weder in der compilierten Form, noch lässt sich ein anderes externes Fenster anklicken. Der Mauszeiger bleibt solange der Pfeilzeiger.

[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) :gruebel:

[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)

[Dejan Vu]

Zitat:

Zitat von BUG (Beitrag 1279038)

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:

Zitat von himitsu (Beitrag 1279041)

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