Prozessprioritäten / CPU-Auslastung mit X2

So, weil wir das ja eben erst ausführlich durchdiskutiert haben, ist mr grad was aufgefallen:
Hier laufen ständig 2 Boinc-Threads (Seti oder CPDN), wie es sich gehört mit "Idle"-Priorität.
Ergebnis: 100% CPU-Last, je ca. 50% für die beiden Threads.
Starte ich jetzt eine andere CPU-intensive Anwendung, die eigentlich einen Kern voll auslasten müßte (-> 50% Last im Taskmanager) fällt auf, das dies nicht passiert. Stattdessen teilen läuft der eine Boinc-Thread mit 50% Last weiter, und auf dem anderen Kern teilen sich der 2. Boinc-Thread und die Anwendung die CPU-Zeit haben also im Taskmanager beide ca. 25% Last. Erst, wenn ich beide Boinc-Threads manuell auf einen Kern schiebe, kriegt die andere Anwendung tatsächlich die komplette möglichen 100% auf einem Kern. Das ist übrigens nicht nur ein Problem mit einer falschen Anzeige, sondern die Anwendung ist tatsächlich nur ca. halb so schnell, wie sei sein könnte, wenn sie einen Kern für sich alleine hat.

Dasselbe läßt sich auch gut mit Prime95 nachvollziehen: 2x Prime mit idle-Priorität, einmal mit normaler Prio -> auch hier kriegt der Thread mit normaler Prio nicht die volle CPU-Zeit, sondern teilt sie sich gleichmäßig mit dem idle-Prime-Thread, der auf derselben CPU läuft.

Tritt dieser Effekt bei anderen Leuten auch auf (sprich, ist der Windows-Scheduler tatsächlich so beknackt, wie er sich im Moment bei mir anstellt), oder ist da bei meinem System was nicht in Ordnung?

Cherry

Was mich interessiert: Hast du den Windows Patch KB896256 und/oder den AMD DualCore Optimizer installiert?

@Cherry: Wenn Du schon dabei bist, den Windows Scheduler für beknackt zu halten, dann fang zuerst mal bei Dir selbst an, einiges klar zu stellen. Du schreibst von Threads, kannst aber mit den von Dir beschriebenen Mitteln lediglich die darüber liegenden Prozesse beobachten bzw. beeinflussen. Zum Beobachten von Threads brauchst Du ein anderes Tool.
Desweiteren ist so ein Scheduling etwas komplizierter, als nur die Rechenzeit auf laufende Prozesse gerecht aufzuteilen. Schliesslich will das System ja noch vom User bedient werden können und auf Dinge reagieren, welche Dir als User, mal sallop gesagt am Ar*** vorbei gehen.
Angenommen, Prime95 wäre wirklich nur der Algorithmus zum Berechnen, dann könntest Du diesen nur über den Taskmanager gewaltsam killen, um ihn zu beenden. Aber nein, Prime95 ist eine Single-Threaded Anwendung, welche Maus- und Tastatureingaben verarbeitet. Um das zu tun, kann Prime95 nicht zu 100% nur berechnen.
Es kommt noch dazu, dass Windows die Priorität der Anwendung, welche den Eingabefokus besitzt, um (mindestens) eine Einheit erhöht.

Wenn eine Prime95 Instanz auf Idle-, die andere auf Normalprio läuft (derselben CPU zugewiesen), musst Du nur mal mit der Maus mal die eine, mal die andere und mal eine völlig andere Anwendung in den Vordergrund bringen und dabei die Prozessauslastung beobachten.
Vielleicht wird Dir damit das Verhalten deutlich.

Außerdem müßtest Du mal genauer angeben, wie Du Prime95 etc. startest. Prime95 läßt sich bei mir nämlich nur dann mehrmals gleichzeitig starten, wenn ich -A1 bzw. -A2 angebe. Stellt sich die Frage, was Du dann in Prime95 in jeder Instanz unter "Advanced", "Affinity" eingestellt hast.

Mach am Besten mal eine Liste, wann Du welche Prozesse startest, welchen CPUs die zugeordnet sind, welche Priorität sie haben, und welche Auslastung sie bei den CPUs hervorrufen. Das ist mir in Deinem Posting nicht ganz klar, sorry.

Ray schrieb:

Wenn eine Prime95 Instanz auf Idle-, die andere auf Normalprio läuft (derselben CPU zugewiesen), musst Du nur mal mit der Maus mal die eine, mal die andere und mal eine völlig andere Anwendung in den Vordergrund bringen und dabei die Prozessauslastung beobachten.
Vielleicht wird Dir damit das Verhalten deutlich.

Zum Vergrößern anklicken....

Es ist völlig irrelevant, ob eines der Prime-Fenster aktiv ist, oder eins von ner anderen App. An der der Lastverteilung ändert das nichts. Prime war ja von mir nur als Test gedacht, nachdem ich festgestellt habe, daß Boinc sich nicht so kooperativ verhält wie erwartet, und von Boinc ist im Gui außer dem Trayicon vom Manager nix zu sehen.
Aufgefallen ist mir das ganze, als ich gestern mal spaßeshalber versucht habe, nen pdf-passwort per Brute-Force zu knacken. Das Passwort-Recover-Tool ist singlethreaded. Es hat ca. 6000 Keys pro Sekunde getestet. Ich hab dann mal zufällig in den Taskmanager gesehen, und festgestellt, daß das Recover-Tool nur ca. 25% CPU-Last hatte, statt der erwarteten 50% (ein Kern komplett ausgelastet). Ich habe erst gedacht, ok, eventuell dauert das Platten-IO zu lange, aber die Platte war eigentlich recht ruhig. Also hab ich mal spaßeshalber Boinc beendet, und siehe da: plötzlich kommt das Tool auf 50% Last und schafft 12000 Keys pro Sekunde.

Daraufhin hab ich dann eben auch mal mit Prime (2*idle, 1*normale Priorität) experimentiert.
Zu Prime: es gibt hier natürlich 3 (identisch konfigurierte) Prime-Verzeichnisse, so daß ich es 3mal separat starten kann.
Gestartet werden sie erst alle 3 mit Idle-Priorität und ohne Zuweisung auf einen bestimmten Core. Daraufhin erzeugt ein Prime-Prozeß 50% Last (der hat nen Core für sich alleine), und die beiden anderen Teilen sich den zweiten Core und erzeugen je 25% Auslastung.

Quizfrage: was passiert, wenn ich einem der beiden Prime-Prozesse (die auf dem gleichen Core rechnen) ne höhere Priorität gebe?
Antwort: nix. Die beiden teilen nach wie vor die zur Verfügung stehende Rechenzeit gleichmäßig untereinander auf.

Was ich will ist folgendes: auf meinem SC lief auch immer eine Boinc-App, mit idle-Priorität. Wenn nun irgendein anderes Programm CPU-Zeit brauchte, wurde ihm diese gegeben, bis zum Extremfall, wo für Boinc (oder Prime, das ist egal) quasi keine Rechenzeit mehr übrig blieb.
Auf dem DualCore laufen nun 2 Boinc-Apps (oder Prime), ebenfalls mit Idle-Priorität. Ich erwartete mir nun eigentlich, daß eine mit höherer Priorität gestartete Single-Thread-Applikation nun auf dem Core, auf dem sie läuft, auch die volle Rechenkapazität zugeteilt kriegt (so, wie es auf dem SingleCore ja auch funktioniert hat), und Boinc auf diesem Core quasi keine Rechenzeit mehr bekommt.
Quasi:
Ausgangspunkt: 2x Boinc, mit idle-Prio
Boinc1 50% CPU-Auslastung, Boinc2 50% CPU-Auslastung (Anzeige im Taskmanager), es ist anzunehmen, daß auf jeder CPU eine Boinc-App läuft und auch dort bleibt.
Ich starte jetzt was CPU-intensives (z.b. Prime) mit normaler Priorität, und erwarte folgende Aufteilung der Rechenzeit:
Boinc1 50% (auf Core0), Boinc2 (auf Core1) 0%, Prime (auf Core1) 50% oder:
Boinc1 25%, Boinc2 25% (diesmal Boinc2 vom Scheduler auf Core0 migriert) und Prime 50% (auf Core1)
Was jedoch passiert ist folgendes:
Boinc1 50% (auf Core0), Boinc2 25%, Prime 25% (die beiden auf Core1)

Was ich mich in dem Moment frage: warum klaut Boinc2 Rechenzeit, die eigentlich Prime komplett erhalten müßte, weil Boinc2 mit niedrigere Priorität arbeitet?
Erst, wenn ich von Hand beide Boinc-Threads auf denselben Core schubse, und Prime dem anderen zuweise, dann kriegt es tatsächlich die maximal mögliche CPU-Zeit.

Noch ne Anmerkung zu dem oben: ich weiß, daß es nicht 50/50 oder 50/25/25 aussieht, sondern immer paar % weniger sind, weil ab+zu auch andere Applikationen was tun. Aber diese paar Prozent hab ich jetzt ignoriert, weil sie mit dem Problem nichts zu tun haben.

Wie gesagt, auf dem SingleCore gings ja auch, das die Idle-Tasks den höherpriorisierten komplett Platz gemacht haben.

Cherry
PS: wegen dem Patch schau ich gleich nochmal

Cherry schrieb:

Zu Prime: es gibt hier natürlich 3 (identisch konfigurierte) Prime-Verzeichnisse, so daß ich es 3mal separat starten kann.
Gestartet werden sie erst alle 3 mit Idle-Priorität und ohne Zuweisung auf einen bestimmten Core. Daraufhin erzeugt ein Prime-Prozeß 50% Last (der hat nen Core für sich alleine), und die beiden anderen Teilen sich den zweiten Core und erzeugen je 25% Auslastung.

Quizfrage: was passiert, wenn ich einem der beiden Prime-Prozesse (die auf dem gleichen Core rechnen) ne höhere Priorität gebe?
Antwort: nix. Die beiden teilen nach wie vor die zur Verfügung stehende Rechenzeit gleichmäßig untereinander auf.

Zum Vergrößern anklicken....

Tatsache, kann ich bestätigen. Ziemlich bescheuertes Verhalten von Windows.

Bestätigt meine Vermutung, daß es für mehrere Prozessoren einfach sehr schlecht programmiert ist.

Im Übrigen scheinen Prozesse niemals auf einer CPU zu bleiben, sondern ständig hin- und herzuwechseln. Einmal bestätigt dadurch, daß ein Programm, daß eine CPU voll auslastet, im Task-Manager beide zu 25% auslastet statt eine zu 50%, und außerdem bestätigt dadurch, daß viele Spiele besser laufen, wenn man sie fest auf einen Kern zwingt.

Gut danke, ich bin also doch nicht völlig verblödet

Der Hotfix hat Verhalten übrigens deutlich verbessert, perfekt ist es aber nach wie vor nicht. Ich werd bei Gelegenheit nochmal den DualCore-Optimizer austesten, aber das kann ich erst machen, wenn ich wieder physischen Zugriff auf das System habe.

Das letzte Mal wollte es nämlich mit installierem DC-Optimizer nichtmehr booten, und wenn ich in den nächsten Stunden nicht an meinen Rechner komme, weil er nicht hochfährt, wird der Rest der Nacht verdammt langweilig.

Cherry

Cherry schrieb:

Ich werd bei Gelegenheit nochmal den DualCore-Optimizer austesten,

Zum Vergrößern anklicken....

Der läuft bei mir bereits.
Wie Du siehst, bringt er in der Hinsicht gar nichts.
Ist aber auch klar, da er für ein ganz anderes Problem gedacht ist.

Cherry schrieb:

Der Hotfix hat Verhalten übrigens deutlich verbessert, perfekt ist es aber nach wie vor nicht.

Zum Vergrößern anklicken....

Oder auch nicht... warum auch immer, beim ersten Test hats geklappt, jetzt macht es schon wieder nicht, was erwartet...
Ehrlich gesagt, hats mich beim ersten Versuch sowieso gewundert, denn so wie ich den KB-Artikel verstanden habe, ändert der Hotfix ja nix am Scheduler, sondern ist vor allem als Lösung für Probleme im Zusammenhang mit Cool'n'Quiet / SpeedStep auf DualCores gedacht. Und meine CPU läuft immer auf vollem Takt, daher hätte ich da auch keine Probleme haben dürfen.

Was übrigens hilft, ist, die CPU-hungrige Applikation auf "Echtzeit"-Priorität zu setzen, aber da muß ich ja dann jetzt öfter im Taskmanager rumspielen, als es vorher mit dem Singlecore-System nötig war. So schön die Extra-Rechenleistung ist, aber wenn der Scheduler damit nicht richtig umgehen kann, bzw. die vergebenen Prioritäten (durch welche Effekte auch immer) praktisch mehr oder weniger ignoriert werden, kotzt mich das schon ein bißchen an

Verdammt, es sieht so aus, als hätte ich nen Grund für ein Update auf Vista gefunden (falls da der Scheduler cleverer ist).

Cherry

Cherry schrieb:

Verdammt, es sieht so aus, als hätte ich nen Grund für ein Update auf Vista gefunden (falls da der Scheduler cleverer ist).

Zum Vergrößern anklicken....

Geht mir ähnlich, inklusive des "Verdammt".

Cherry schrieb:

Es ist völlig irrelevant, ob eines der Prime-Fenster aktiv ist, oder eins von ner anderen App.

Zum Vergrößern anklicken....

Wenn z.B. drei Prime-Instanzen alle mit normaler Priorität ohne Corebeschränkung laufen, teilt sich die Rechenzeit auf alle auf, wobei ich nicht beobachten konnte, dass es jeweils 33% sind. Irgendeine Instanz bekommt bekommt immer etwas mehr. Aktiviere ich aber eines der Primefenster, bekommt diese Instanz auch gleich mit Abstand ein paar Prozente mehr.

Cherry schrieb:

Quizfrage: was passiert, wenn ich einem der beiden Prime-Prozesse (die auf dem gleichen Core rechnen) ne höhere Priorität gebe?
Antwort: nix. Die beiden teilen nach wie vor die zur Verfügung stehende Rechenzeit gleichmäßig untereinander auf.

Zum Vergrößern anklicken....

Eine Stufe höhere Priorität scheint tatsächlich nichts zu bewirken, da muss man schon
"Hoch" oder gar Echtzeit nehmen, dann schon.

Aber es bleibt schon ein schaler Beigeschmack, da muss ich Dir recht geben.
Bei einer Single-Core Maschine ist die Rechenzeitaufteilung noch einigermassen nachvollziehbar, bei zwei Kernen wird's in der Tat manchmal unverständlich.
Bleibt die Frage, ob die Messung und die Ausgabe verfälscht sind, oder ob's tatsächlich so läuft.
Abgesehen davon war und ist Windows noch nie ein Echtzeitbetriebssystem gewesen.

Die Anzeige im Taskmanager scheint zu stimmen, die Anwendungen laufen tatsächlich langsamer. Ich sehs halt immer gut an diesem PDF-Passwortknack-Tool, weil es immer live anzeigt, wie schnell es denn da grade ist. Und das korreliert gut mit dem, was der Taskmanager sagt.

Naja, dann weiß ich halt, daß ich da in Zukunft drauf achten muß, und es bleibt wie gesagt die "Hoffnung" auf Vista.

Oder: hat jemand nen 2003 als Desktop-OS laufen? Wenn ja, kommt da der Scheduler besser mit DualCore klar, und wie schlägt es sich generell im Vergleich mit XP?

Cherry

Ray schrieb:

Abgesehen davon war und ist Windows noch nie ein Echtzeitbetriebssystem gewesen.

Zum Vergrößern anklicken....

Ein Echtzeitbetriebssystem ist etwas ganz anderes. Um das hier angesprochene Problem in den Griff zu bekommen, muß ein Betriebssystem nicht echtzeitfähig sein.

Lord Voldemort schrieb:

Ein Echtzeitbetriebssystem ist etwas ganz anderes. Um das hier angesprochene Problem in den Griff zu bekommen, muß ein Betriebssystem nicht echtzeitfähig sein.

Zum Vergrößern anklicken....

Das war auch nicht ernst gemeint.

Hab auf meinem Opt170 Rechner mal Vista Beta2 64 Bit gestartet und 4 Instanzen Prime95 64 Bit vorbereitet. Alle Tests noch aus.
Dann zwei gestartet. Auslastung wie erwartet 2 x 50%.
Jetzt den dritten Test. Ergebnis 25 - 50 - 25. Oh, interessant!
Hmm. Bei drei gleichwertigen Prozessen lassen sich die Zeitscheiben bei zwei Cores vielleicht so wirklich einfacher aufteilen. Kann ich irgendwo etwas nachvollziehen.
Also dazu noch den vierten Test starten. Jetzt würde ich aber wirklich eine gerechte Aufteilung erwarten, aber: 50-17-17-17!
Alle Prime-Instanzen laufen auf beiden Cores mit Low Priority.
Ich kann's drehen wie ich will, eine der vier Prime-Instanzen läuft immer mit 50%.

Schon sehr merkwürdig.
Ich vergleiche das jetzt mal mit XP64 Bit. Mehr Windows Varianten hab ich leider nicht.

OMFG! Was für ein Schrott.

So, das Ganze unter XP64:
2 x Prime: 50-50
3 x Prime: 25-50-25
4 x Prime: 25-25-25-25 (ha, bin etwas erleichtert )
Und was passiert bei 5 Instanzen?
5 x Prime: 25-17-17-17-25

Übrigens, wer immer noch n Verzeichnisse für n Primeinstanzen benützt, es geht auch einfacher: Pro Instanz einen Link auf Prime95.exe anlegen und beim Aufruf -An eintragen.
.
.
Edit:
Scheisse, wollte gerade eine der 17% Instanzen auf Realtime Prio setzen, jetzt geht nur noch die Maus, der Rest sitzt fest...

also wenn win xp64 das kann wärs irgensdwie komisch wenn Vista das als Vollversion nicht hinkrigt. dashalb würd ich den bug bei vista betastatus-bedingt sehen.

So, das Ganze nochmal unter XP32:
2 x Prime: 50-50
3 x Prime: 38-31-31 bis 44-28-28 (schwankt ziemlich)
4 x Prime: 34-22-22-22 bis 40-20-20-20 (ebenfalls schwankend)
5 x Prime: 27-18-18-18-19 (eine bis max. 30, die anderen immer unter 20)
Eine Instanz gestoppt und nun recht stabil
4 x Prime: 25-25-25-25
Wieder eine Instanz gestoppt und nun ebenfalls stabil
3 x Prime: 33-33-33

Vielleicht eignet sich Prime95 für solche Tests auch nicht.
Immerhin, die Verteilung unter XP64 ist erscheint mir insgesamt stabiler.

Wobei ich glaube, dass Windows stest der Anwendung deren Programmfenster zuletzt im Vordergrund war mehr Rechenleistung zuweist. Ich merke dies gerade beim Erstellen eines Panoramas und der Verschlüsseln von Dateien. Hol ich die Panoramasoftware in den Vordergrund erlebt diese einen Geschwindigkeitszuwachs. Klicke ich dann die Verschlüsselungssoftware an, dann sehe ich im Hintergrund, dass die Panoramasoftware langsamer wird. Vielleicht sind hier die Unregelmäßigkeiten bei der Ressourcenverteilung zu suchen. Wohl gemerkt gilt diese Aussage bloß für meinen Singel Core Prozessor. Ich denke aber bei einem Dual Core Modell verhält es sich ähnlich.

Ich frage mich, ob die Jungs bei Microsoft solche Tests auch machen.
- Wie ich in irgendeinem Thread schonmal sagte: Idioten. Alles Idioten. Keiner macht was richtig. Alles muß man selber machen. Die ganze Menschheit: nur Idioten.

Eine wirklich erfreuliche Ausnahme ist dieser Thread. Das zeigt mir, daß nicht nur mir so ein "Scheiß" auffällt, sondern auch anderen, wie Euch.
.
.
Edit:
Hm, über diese "Alles muß man selber machen"-Überlegung ist mir aufgefallen: so muß Linux entstanden sein!

Da ich nicht weiss, was Prime95 wirklich alles macht, hab ich mir ein kleines Proggi, einen Process-Time-Eater geschrieben, welcher nur in einer Endlosschleife ein paar unsinnige Integer- und Floatberechnungen durchführt. Keine Ausgaben, ausser kurz am Anfang, keine Eingabemöglichkeiten. Zum Beenden muss es gekillt werden.
Damit keine Übertreibung aufkommt, verpasst sich das Programm selbst beim Start "Idle Priority".
Und siehe da: Solange die Anzahl der gestarteten Zeitfresser gerade ist, ist die CPU-Zeitverteilung konstant gleichmässig.
Bei ungerader Anzahl gibt es unter XP32 Schwankungen, als ob versucht würde, die CPU-Zeit noch gerecht aufzuteilen, unter XP64 erfolgt eine starre Zuteilung, z.B 25-50-25.
Windows verwendet 10 ms Zeitscheiben. Diese mit zwei Prozessoren auf eine ungerade Anzahl von Prozessen, welche als Endlosschleifen laufen, gerecht aufzuteilen, kann nicht funktionieren.

Ich kann jetzt eigentlich nicht sagen, dass MS Scheisse gebaut hat. Man muss auch bei den Applikationen schauen. Wer weiss schon, wann die Apps freiwillig Prozessorzeit abgeben, z.B. wenn ein Thread auf ein Ereignis wartet, wie die Nachrichtenschleifen implementiert sind, wie sie ihre Threads priorisieren usw.

Ray schrieb:

Windows verwendet 10 ms Zeitscheiben. Diese mit zwei Prozessoren auf eine ungerade Anzahl von Prozessen, welche als Endlosschleifen laufen, gerecht aufzuteilen, kann nicht funktionieren.

Zum Vergrößern anklicken....

Warum nicht?

Ich kann jetzt eigentlich nicht sagen, dass MS Scheisse gebaut hat. Man muss auch bei den Applikationen schauen. Wer weiss schon, wann die Apps freiwillig Prozessorzeit abgeben,

Zum Vergrößern anklicken....

Genau da haben sie ja scheiße gebaut. "Freiwillig" is nicht, dann sind wir nämlich wieder bei Windows 3.1. Notfalls (und das ist der Punkt) muß dem Programm halt die CPU entrissen werden. Wird sie auch, nur nicht unbedingt immer früh genug für meinen Geschmack.

was ändert denn die Einstellung:

Systemeigenschaften->Erweitert->Leistungsoptionen->Prozessorzeitplanung ?

ich meine man konnte auch irgendwo immer angeben, dass aktive Fenster immer mehr Priorität bekommen ?!?

aber schon komisch, bestätigt meine Befürchtungen aus dem "alten" Thread

Lord Voldemort schrieb:

Warum nicht?

Zum Vergrößern anklicken....

Vielleicht hätte ich schreiben sollen, eine gerechte Aufteilung ist nicht messbar bzw. darstellbar. In welchem Intervall willst Du 3 Prozesse auf 2 Cores gleichmässig aufteilen und messen?

Lord Voldemort schrieb:

Genau da haben sie ja scheiße gebaut. "Freiwillig" is nicht, dann sind wir nämlich wieder bei Windows 3.1. Notfalls (und das ist der Punkt) muß dem Programm halt die CPU entrissen werden. Wird sie auch, nur nicht unbedingt immer früh genug für meinen Geschmack.

Zum Vergrößern anklicken....

Wenn ein Thread z.B. auf ein Ereignis wartet (einfacher Fall: Timer), dann braucht er keine CPU-Zeit bis das Ereignis eintrifft. Solange gibt er "freiwillig" CPU-Zeit ab. Wenn ein Thread auf Speicher zugreifen will, der auch von anderen Threads gelesen und geschrieben wird, wartet der eine auf den anderen, um Kollisionen zu vermeiden. Auch hier wird "freiwillig" CPU-Zeit abgegeben. Wenn ein Thread Daten über einen Treiber von einer Hardware-Schnittstelle empfängt, braucht er zwischen den Datenpäckchen keine kostbare CPU-Zeit zu vergeuden sondern signalisiert dem OS mittels Eventobjekt, dass er bis zum nächsten Datenpäckchen "freiwillig" jemand anders CPU-Zeit abgibt.
Das ist nicht Windows (ab NT) spezifisch, hat nichts mit Win3.1 zu tun (das kann dies noch gar nicht), sondern ist eine allgemeine Vorgehensweise der Thread-Syncronisation, wie man sie in zig Multi-Threaded Betriebssystemen findet, so auch bei Linux. Wäre dies anders, würdest Du Dich noch sehr viel mehr über das OS aufregen.
Notfalls einem Programm die CPU zu entreisen passiert automatisch dann, wenn das Programm länger als die Zeitscheibe am Stück rechnet, sofern andere Threads mit gleicher oder höherer Priorität zur gleichen Zeit laufen.
Nur eines ist geblieben wie bei Win 3.1: Das Warten auf Tastatur und Mauseingaben kann mittels Nachrichtenschleife geschehen. Der Applikations-Thread gibt dabei solange CPU-Zeit ab, bis eine Nachricht für ihn eintrift. Je nach Anwendung ist diese Vorgehensweise völlig in Ordnung und ist Gang und Gebe. Muss sie noch andere Dinge erledigen, kann sie das mit weiteren Thread(s) tun.

Ray schrieb:

Wenn ein Thread z.B. auf ein Ereignis wartet (einfacher Fall: Timer),

Zum Vergrößern anklicken....

Du redest hier die ganze Zeit von Threads. Der ganze Prozeß, zu dem die Threads gehören, läuft aber schon nicht permanent (logisch), sondern wird schlafen gelegt zu gunsten von anderen Prozessen.