Grundlegende eigenschaften von großrechnern

Multi-User-Fähigkeit / Dabei sind mehrere Benutzer über ein Terminal mit einem Rechner verbunden. Da ein Großrechner Timesharing beherrscht, kann er zwischen den Prozessen der einzelnen Benutzer hin- und herschalten und erweckt trotzdem den Eindruck als würde er dem Benutzer alleine zur Verfügung stehen. Das Betriebssystem muß jedoch zahlreiche Sicherheitsfunktionen implementieren.

Das Terminal, welches die Verbindung zum Großrechner darstellt besteht aus einem Bildschirm, einer Tastatur und einem Verbindungsgerät zum Großrechner. Die Eingabe der Benutzer werden an den Großrechner geschickt, von diesem verarbeitet und die Ausgaben werden zurückgeschickt. Die einzige Aufgabe des Terminals ist es die Ein- und Ausgaben zu puffern.

Diese Art der Rechnerverwendung wurde früher geführt, weil sich einzelne Benutzer keinen Rechner leisten konnten. Später wurde dieser Betrieb in Rechenzentren geführt, wo die Rechnerbenutzung an andere vermietet wurde.

Ausfallsicherheit

Ein Großrechner muß gewährleisten, daß nur unter Einbeziehung bestimmter Sicherheitsmaßnahmen, mehrere Benutzer auf einem Großrechner gleichzeitig arbeiten und auf die Ressourcen zugreifen.

Maßnahmen zur Sicherheitsgewährleistung:
. Meißtens durch Login-ID und Passwort Authentifizierung jedes Benutzers
. Zugriffe auf Ressourcen werden protokolliert
. Rechte der Ressourcen darf nur der Besitzer festlegen
. Versehen jeder Ressource mit einer Zugriffsliste (Access Control List)

Timesharing

Der Mehrprogrammbetrieb wurde anfangs durch das Timesharing-Prinzip gewährleistet. Bei diesem Prinzip werden mehrere Anwendungen gleichzeitig im Hauptspeicher gehalten. Die CPU wird zwischen den Anwendungen vom Scheduler, einer übergeordneten Instanz, in kurzen Zeitabständen hin- und hergeschalten, so daß der Anwender glaubt, daß alle Anwendungen gleichzeitig ablaufen. Um den aktuellen Status der Anwendungen zu sichern, müssen viele Informationen gesichert werden, die von den CPU-Registern über sogenannte Speichersegment-Zeiger bis zum aktuellen Dateiverzeichnis reichen. Vom Scheduling-Algorithmus hängt ab in welcher Reihenfolge den Programmen Rechenzeit zugeteilt wird. Es gibt hier eine Vielzahl solcher Algorithmen. Z.B.:



Scheduling aus Thread-Sicht



Die Thread-Library stellt das Programmierer-Interface zur Erzeugung und Verwaltung von Applikationsthreads dar. Sie verteilt die Threads eines Prozesses auf die zum Prozeß gehörigen LWPs. Es gibt zwei Möglichkeiten, wie LWPs Threads ausführen: gebunden oder ungebunden. Ungebundene Threads werden gemäß ihrer internen Priorität einem beliebigen, gerade zur Verfügung stehenden LWP zugeordnet und von ihm nach Erkennung des Thread-Status ausgeführt. Wenn ein solcher Thread durch einen Synchronisationsmechanismus blockiert wird oder ein anderer Thread ausgeführt werden soll, wird der Thread-Status gesichert, und mit einem anderen (ungebundenen) Thread wird genauso verfahren. In manchen Fällen, z.B. bei Realtime-Anwendungen, ist es nötig, daß Threads eine ganz bestimmte, systemweite Priorität haben. Dies ist bei ungebundenen Threads nicht möglich, da sie nur innerhalb des Prozesses sichtbar sind. Deshalb gibt es gebundene Threads, bei deren Erzeugung auch ein LWP erzeugt wird. Dieser LWP führt nur diesen einen Thread aus, und der Thread erhält dadurch implizit die systemweite Priorität des LWPs. Grundsätzlich ist die Thread-Library in der Lage zu bestimmen, wieviele LWPs nötig sind, um den Pool von ungebundenen Threads auszuführen. Wichtig ist dabei, daß nicht dadurch eine Blockierung des Prozesses eintritt, daß es keine (unblockierten) LWPs mehr gibt, obwohl noch lauffähige Threads in dem Prozeß vorhanden wären. Auf der anderen Seite wäre es nicht sinnvoll, für jeden Thread ein LWP zu erzeugen, weil dann einige LWPs ungenutzt wären und unnütz System Ressourcen verbrauchen würden. Deshalb erzeugt die Library zunächst eine Default-Anzahl von LWPs. Wenn nun alle LWPs blockiert sind (z.B. durch Terminal Operationen), erhält der Prozeß vom Betriebssystem ein Signal (SIGWAITING), und die Thread-Library erzeugt einen neuen LWP, sofern es noch lauffähige Threads in dem Prozeß gibt.




Scheduling aus Prozeß-Sicht




Es gibt drei Scheduling-Klassen, Timeshare (TS), System (SYS) und Realtime (RT). Jeder Prozeß erhält seine Scheduling-Klasse und die entsprechende Priorität innerhalb dieser Klasse von dem Prozeß, der ihn erzeugt hat. Das Ziel der Timesharing-Strategie ist es, sowohl interaktiven Prozessen gute Antwortzeiten zu liefern, als auch für einen guten Durchsatz von rechenintensiven Prozessen zu sorgen. Deshalb wird jedem (Timesharing-)Prozeß eine Zeitscheibe von wenigen hundert Millisekunden zugeordet. Diese ist bei Prozessen mit höherer Priorität kürzer und bei Prozessen mit niedriger Priorität länger. Innerhalb der Timesharing-Klasse werden die Prioritäten dynamisch verändert. Die Priorität von einem \"schlafenden\" Prozeß wird erhöht, wenn er zuvor nur sehr kurz die CPU belegt hat und dann unterbrochen oder blockiert wurde. Entsprechend wird die Priorität eines Prozesses gesenkt, der schon recht lange die CPU belegt. Dies ist die systemgesteuerte Komponente der Timesharing-Priorität. Die System-Scheduling-Klasse hat feste Prioritäten und ist ausschließlich für Kernel- Prozesse (-threads) reserviert. Anwender können der System-Klasse weder einen Prozeß hinzufügen noch einen aus ihr entfernen und auch deren Priorität nicht ändern. Auch die Prioritäten der Realtime-Scheduling-Klasse werden vom System nicht verändert, damit diese (zeitkritischen) Prozesse in einer vorherbestimmbaren Reihenfolge abgearbeitet werden können. Die Realtime-Prioritäten können nur von privilegierten Benutzern geändert werden. Aus den Prioritäten der einzelnen Scheduling-Klassen werden globale Prioritäten errechnet. Die (lauffähigen) Prozesse werden in Dispatch-Queues eingeordet. Die Prozesse innerhalb einer Dispatch-Queue haben die gleiche globale Priorität. Innerhalb der Dispatch-Queue wird das Round-Robin-Verfahren angewendet, d.h. neu ankommende und gerade bearbeitete Prozesse werden hinten angefügt, so daß jeder Prozeß dieser Priorität einmal an der Reihe ist. Der Kernel-Scheduler ordnet immer den ersten Prozeß der Dispatch-Queue mit der höchsten Priorität einer verfügbaren CPU zu. Wird ein Prozeß mit höherer Priorität lauffähig, wird dieser anstelle des gerade laufenden Prozesses der CPU zugeordnet, und letzterer suspendiert. Das bedeutet, solange es noch lauffähige Realtime-Prozesse gibt, können keine System- und keine Timesharing-Prozesse laufen. Nicht-lauffähige, also \"schlafende\", Prozesse werden in Sleep-Queues eingeordnet. Prozesse in derselben Sleep-Queue warten auf das gleiche Ereignis, z.B. daß ein Synchronisationsobjekt frei wird. Innerhalb dieser Sleep-Queue sind sie nach ihrer Priorität geordnet. Tritt nun dieses Ereignis ein, wird der Prozeß, der an erster Stelle steht, also der mit der höchsten Priorität, lauffähig.

Wenn nicht genügend Hauptspeicher zur Verfügung steht, um alle zur Zeit aktiven Prozesse darin zu verwalten, werden einzelne Seiten davon in den
Sekundärspeicher ausgelagert, der Prozeß bleibt dabei aber lauffähig. Diesen Vorgang nennt man Paging. Wenn diese ausgelagerten Seiten gebraucht werden, muß der Prozeß solange schlafen, bis diese Seiten zurück in den Hauptspeicher gelesen wurden. Wenn noch größerer Speichermangel auftritt, müssen Prozesse
vollständig auf den Sekundärspeicher ausgelagert werden. Dies ist unter Swapping zu verstehen. Beim Paging, aber besonders beim Swapping, kommt es zu
Verzögerungen in der Ausführung, bis der Prozeß wieder im Speicher verfügbar ist. Dies ist für zeitkritische Anwendungen, also Realtime-Prozesse, nicht akzeptabel.
Deshalb haben Realtime-Prozesse die Möglichkeit, Speicherseiten im Hauptspeicher dauerhaft zu belegen.

Grafik zeigt vereinfacht alle Zustände, in denen sich ein Prozeß befinden kann.