Ich habe das Gefühl, Deine Antwort geht an meiner Frage vorbei.
Ich setze jetzt einmal voraus, dass Programmierer nicht grundlos Threads einsetzen sondern dort, wo sie einen Sinn haben. Es geht ja auch nicht um eine fast 100%ige Skalierbarkeit (so wie es bei komplett unabhängigen Aufgaben, wie dem Rendering, möglich ist) sondern um eine Aufteilung der Rechneraufgaben. Typischerweise wird das User Interface in einem Thread behandelt und die Business Logik in einem zweiten.
Ich gebe Dir auch vollkommen recht, dass sich manche Algorithmen nicht oder nur schwer parallelisieren lassen und dass sich Programmierer mit den Abhängigkeiten beschäftigen müssen.
Ein Flugsimulator gehört aber nicht zu diesen Algorithmen. Dort bietet sich die Aufteilung in Simulation und Graphikdarstellung ja geradzu an. Zwischen diesen beiden Teilen gibt es nur EINE Schreib-Lese-Abhängigkeit: die Simulation berechnet die neue Position und Fluglage und die Graphikdarstellung übernimmt sie, um die Sicht nach draußen zu berechnen.
Die Eingabe der Steuerbefehle, die Panels, der AI-Traffic, die ATC usw. sind alles Dinge, die auch in Threads abgebildet werden können. Auch hier liegen nur einfache Schreib-Lese-Abhängigkeiten vor. Aber bei allen bisher aufgezählten Threads muss NIE ein Thread auf den anderen warten. Es muss nur der jeweilige Schreibvorgang atomar erfolgen. Das Lesen wartet aber nie darauf sondern nimmt den Wert, der gerade da ist.
Ich will aber jetzt gar nicht auf eine Implementierung des Flugsimulators mit Threads eingehen. Mir geht es nach wie vor darum, wieso kann das Betriebssystem nicht diese schon vorhandenenThreads automatisch auf die CPUs aufteilen?
____________________________________
Alex
Home Page: http://homepage.mac.com/alfora/
O\'Hare Approach Control: \"United 329 heavy, your traffic is a Fokker, One o\'clock, three miles, eastbound.\"
United 239: \"Approach, I\'ve always wanted to say this... I\'ve got the little Fokker in sight.\"
|