WinFuture-Forum.de: [Exkurs] In Einem Land Vor Unserer Zeit - WinFuture-Forum.de

Zum Inhalt wechseln

Beiträge in diesem Forum erhöhen euren Beitragszähler nicht.
Seite 1 von 1

[Exkurs] In Einem Land Vor Unserer Zeit Entwicklung der Aufgabenplanung auf x86-basierten Systemen

#1 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 7.762
  • Beigetreten: 20. Juli 07
  • Reputation: 858

geschrieben 04. Oktober 2017 - 20:02

Wir schreiben das Jahr 2017 und befinden uns mitten im Krieg der Kerne.

Manch einer mag sich nun fragen: Warum eigentlich? Was ist das eigentlich? Was ist überhaupt ein Thread? Was mache ich damit, außer etwas zu nähen?

Dazu müssen wir eine kleine Reise in die Vergangenheit antreten, dahin, wo es zuhause sowas alles noch nicht gab, und wenn, dann nur in einer sehr einfachen Form.




Schauen wir zunächst in die Zeit des Intel i80286 ("Zwo-Sechsenachsjer"). Das war ein Prozessor mit einer 16bit-Architektur: Übergebene Befehle konnten entsprechend maximal zwei Byte groß sein.

Zu dieser Zeit war Aufgabenplanung sehr einfach mit den Worten "mach's Dir selber" umschrieben. DOS, das Betriebssystem auf 80286er PCs, konnte noch keine Aufgabenplanung: Man gab einen Befehl ein und der wurde abgearbeitet, und wenn er fertig war, dann gab es den nächsten. Man konnte natürlich mehrere Befehle in einem Befehlsstapel zusammenfassen - das nannte sich auch damals schon Batchdatei -- aber auch dort wurde stur von oben nach unten abgearbeitet.

Hatte man zwei Befehle und einer war einem wichtiger als der andere, dann mußte man diesen eben zuerst ausführen.

Windows bis 3.1 konnte man auf einer 80286-CPU ebenfalls ausführen. In diesem Fall wurde das gerade aktive Fenster ausgeführt; alle übrigen Fenster waren eingefroren und taten solange nichts, bis man selbst diesem per Alt-Tab den Focus gab (oder das gerade aktuelle Fenster geschlossen wurde).

Dann wurde der Nachfolger des i80286 freigegeben, der i80386. Das war die erste echte 32bit-CPU, deren Befehlssatz auch heute noch vollständig unterstützt wird.

Damit wurde es möglich, Speicherbereiche aus dem RAM auszulagern und Aufgaben im Speicher gegeneinander zu isolieren (über das sogenannte Ringmodell). Führte man sein Windows nun auf einem 80386er Prozessor aus, dann war es in der Lage, darunter ausgeführte Aufgaben "so etwas wie gleichzeitig" auszuführen. Applikationen konnten so geschrieben werden, daß sie die Kontrolle über die CPU abgaben, sodaß diese nun eine andere Aufgabe ausführen konnte. Das nannte sich cooperative multitasking: Anwendungen mußten miteinander kooperieren,damit das funktionierte. Wollte eine Anwendung die CPU-Kontrolle nicht abgeben, behielt sie diese eben.

Mit Windows 95 besserte sich das. Damit wurde es möglich, Aufgaben, die nicht freiwillig Ressourcen rausgeben wollten, diese wegzunehmen. Hatte man also eine Anwendung und diese mußte auf Benutzerinteraktion oder sonst eine Reaktion z.B. der Hardware warten, dann konnte diese entweder die Kontrolle ans System zurückgeben - oder dies nicht tun, in welchem Fall das System dann einfror.

Anwendungen mußten nun nicht mehr kooperieren. Stattdessen wurde ein Aufgabenplaner implementiert, welcher Anwendungen Prioritäten zuweisen konnte und auf dessen Basis man "wichtige" Anwendungen "unwichtigeren" vorziehen konnte. Anwenden mußten nun per "Meldung an die CPU" (cf. Interrupt) Bescheid geben, wenn sie etwas haben wollten: dies im Gegensatz zum bisherigen Modell, bei dem sie tun konnten, was sie wollten, bis sie es freiwillig gelassen haben.

Dieses Modell nannte man Präemptives Multitasking, auf der Basis, daß es nun einen Prozeß gab - den Taskplaner -- welcher Aufgaben ungefragt unterbrechen konnte.

Zur selben Zeit, jedoch an anderer Front, wurde für Mehrprozessorsysteme entwickelt. Auf dieser Basis entstanden Anwendungen, die in der Lage waren, auf mehr als nur einer CPU ausgeführt zu werden. Das war zu dieser Zeit hauptsächlich eine symmetrische Verarbeitung ("SMP" wie "Symmetric Multi-Processing").

Hierzu wurden erstmals Aufgaben nicht mehr atomar, sondern molekular verstanden: die Aufgabe war nicht unteilbar, sondern sie konnte in Teile zerlegt werden und diese Teilaufgaben unabhängig voneinander erledigt werden.

Paradebeispiel für die symmetrische Multiprozessorverarbeitung ist das Sortieren. Bildlich: Wir haben einen Stapel Skatkarten und wollen diesen sortieren. Um das hinzubekommen, können wir verschiedene Wege gehen. Einer davon ist, unsere 32 Karten in gleiche Teile zu zerlegen - zB 2x 16 -- und statt einer CPU 32 Karten nun zwei CPUs jeweils 16 Karten zum Sortieren zu geben.

Das hat Auswirkungen auf Laufzeit und Komplexität der Aufgabe. Zum einen wird die Aufgabe schneller, da gleichzeitig auf verschiedenen Recheneinheiten abgearbeitet. Zum anderen muß jedoch die Aufgabe zerlegt und die Ergebnisse wieder zusammengefügt werden.


Auf dieser Basis entwickelten sich auch auf Ein-Prozessor-Systemen wie denen zuhause das Modell des Multithreadings. Das war sozusagen das, was die Mehrprozessorsysteme direkt abarbeiten konnte, abgebildet über das System des Taskplaners eines präemptiven Multitaskingsystems. Aufgaben konnten so trotz des einzelnen Rechenwerks schneller abgearbeitet werden, da nun nicht mehr auf unbeteiligte, aber länger laufende Anwendungsteile gewartet werden mußte. Außerdem konnte man von der Multiprozessor-Forschung profitieren, da man nun eine Vorstellung hatte, wie (Anwendungs-)Laufzeiten und die Anzahl ausführender Threads im Zusammenhang standen, wodurch man teilweise signifikante Zeitersparnisse gewann.

Threads sind dabei unbeschränkter als eine ausführende Einheit in einem symmetrischen Multiprozessorsystem. Man kann sich das ein bißchen vorstellen wie: Hier haste ne Aufgabe, und jetzt verschwinde. Von dem Thread sieht und hört man dann nichts mehr, soweit dieser nicht anderweitig Änderungen am System anstellt. Will man wissen, was der Thread macht, muß man nachfragen; das gilt insbesondere auch, um zu erfahren, ob der Thread überhaupt schon fertig ist mit der Aufgabe.

Dies im Gegensatz zu einer Ausführungseinheit in einem SMP-System: Hier werden Aufgaben grundsätzlich halbiert und es wird erwartet, daß beide beteiligten Einheiten gleichzeitig fertig werden. Im Gegenzug heißt das aber auch, daß sich die Recheneinheiten in einem SMP-System immer die Waage halten müssen, sodaß hier immer nur in Größenordnung von Zweierpotenzen viele Recheneinheiten verbaut sein können (jeweils paarweise): also 2, 4, 8, 16 usw.

Irgendwann begann man sich dann zu fragen: moment mal, wir haben hier eine CPU mit einer Recheneinheit, die irgendwie alleine viele viele Threads verarbeiten soll bzw. muß. Warum eigentlich? Können wir das nicht anders machen?

Das war der Grundstein der sogenannten Core-Architektur, die die Softwarethreads in Hardware abbildet.

Zunächst stellte man fest, daß der Pfad eines Befehls durch die CPU-Register diese in den meisten Fällen nicht auslastete. Die Antwort auf die Frage, wie man dies ändern könnte, wird als Hyper Threading bezeichnet: eine physikalische CPU wird als mehrere 'virtuelle' CPUs verstanden, wobei eine den realen Registerpfad abbildet, eine oder ggf sogar mehrere andere dem vorhergehenden Befehl einen weiteren nachschieben, noch bevor der erste die CPU verlassen hat.

Dann ging man mit voranschreitender Miniaturisierung dazu über, mehrere Rechenwerke in ein Gehäuse zu packen. Das wurde möglich, da kleinere Rechenwerke nun zu mehr Platz in einem ähnlich großen Gehäuse führten.

Plötzlich hatte man eine CPU - eine physikalische -- die zwei CPUs im Sinne von zwei Recheneinheiten -- in sich vereinte.

Für die Aufgabenplanung von Windows änderte sich dadurch nicht sonderlich viel. Es mußte lediglich bekannt werden, daß nun mehr als nur eine CPU verbaut sei und daß entsprechend mehr als nur eine CPU für die Aufgabenplanung bereit stünde.

Deshalb sieht die Aufgabenplanung inzwischen etwa so aus:
- Eine Anwendung wurde von ihrem Programmierer so gebaut, daß sie Aufgabenbereiche in einzelne Teile - die Threads -- ausgliedert.

- Der Aufgabenplaner von Windows weist diese Threads zusammen mit all den Threads aller anderen auszuführenden Aufgaben ("Prozesse") an freie Ressourcen zu
- Das kann ein realer Registerpfad auf einem Ein-Kern-System sein, ein virtueller Registerpfad auf einem Ein-Kern-System ("Hyper Threading"), ein realer Registerpfad auf einem Mehr-Kern-System *und* ein virtueller Registerpfad auf einem Mehr-Kern-System (wie zB einer i7-CPU) sein.

- Es kann sogar eine dieser Varianten auf einem Multi-CPU-System sein. Diese werden heutzutage üblicherweise nicht mehr als SMP, sondern als NUMA-System verwaltet, was auf Grundlegendste heruntergebrochen auch nichts anderes bedeutet, daß einfach mehr (Hardware-)Threads zu den bereits vorhandenen hinzukommen.


In Bildern gesprochen:

- Im i80286-System rennt ein Mitarbeiter rum und macht systematisch eins nach dem anderen (DOS) oder erledigt Aufgaben auf Zuruf (Windows)
- Im i80386-System unter Windows 3.x rennt der Mitarbeiter rum, schafft bis er nicht mehr schaffen kann, dann rennt er woanders hin
- Im i80386-System unter Windows 9x rennt der Mitarbeiter rum, arbeitet eine Aufgabe ab, bis plötzlich eine große Hand aus der Decke kommt und ihn an eine andere Aufgabe setzt, dann macht er dort weiter
- Im SMP-System wird unser Mitarbeiter geklont und die beiden Mitarbeiter-Kopien machen im selben Büro so ziemlich haargenau dasselbe, aber mit verschiedenen Teilaufgaben
- Per Thread-Architektur macht unser Mitarbeiter jetzt irgendeine Teilaufgabe von irgendeiner anderen größeren Aufgabe, klopft an wenn er was will und muß alle paar Momente irgendeine andere Teilaufgabe machen
- Per Core-Architektur bekommt er nun ein paar Kollegen zur Seite, jeder mit einer Zelle in einem Großraumbüro und seinen eigenen Aufgaben, die er unabhängig erledigen darf - mitsamt allen Unterbrechungen, die er aus der Threadarchitektur schon kennt
- Und für das Multi-CPU-Modell aus mehreren Core-basierten Prozessoren wird ein zweites Großraumbüro gebaut, das letztlich auch nicht anders aussieht als das erste, aber mit wieder anderen Mitarbeitern und anderen Aufgaben für diese. Auf gemeinsame Ressourcen zugreifen können sie jedoch nicht ohne Weiteres, dafür müssen sie den Dienstweg gehen.
"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild

Anzeige

#2 Mitglied ist offline   Baumanager 

  • Gruppe: aktive Mitglieder
  • Beiträge: 294
  • Beigetreten: 24. Juni 06
  • Reputation: 0

geschrieben 04. Oktober 2017 - 20:59

Alle Achtung RalphS das war ja wirklich anschaulich beschrieben.

Thema verteilen:


Seite 1 von 1

1 Besucher lesen dieses Thema
Mitglieder: 0, Gäste: 1, unsichtbare Mitglieder: 0