Prozeß. 2. Prozesse. 2.1 Einführung

Größe: px
Ab Seite anzeigen:

Download "Prozeß. 2. Prozesse. 2.1 Einführung"

Transkript

1 2. Prozesse 2.1 Einführung Eine wichtige Eigenschaft moderner Computer ist es, dass sie mehrere Aufgaben quasi-gleichzeitig erledigen können. Wie wir in der Vorlesung über Rechnersysteme gelernt haben, gibt es tatsächlich Rechner, welche mehrere Befehlsströme parallel verarbeiten (MIMD-Rechner). Dagegen werden die meisten Rechner mehrere Prozesse nur quasi-parallel ausführen. Insbesondere werden die vielen tausend CPU- Wartezyklen, die z. B. beim Platten-Zugriff auftreten, genutzt, um in dieser Zeit andere Aufgaben zu erledigen. Es liegt also in der Regel nur eine Pseudo-Parallelität vor. Rechner arbeiten also in der Regel im Mehrprogrammbetrieb (Multi-Tasking), selbst, wenn nur ein Nutzer vorhanden ist. Wenn sogar mehrere Nutzer unabhängig voneinander an selben Rechner arbeiten sollen, benötigt man ein Betriebssystem mit Mehr-Nutzer-Fähigkeiten (Multi-User-Betrieb). Das Betriebssystem muss dann alle Abläufe so organisieren, das jeder Nutzer virtuell seinen eigenen Rechner zur Verfügung hat. Die Organisation dieser Quasi-Parallelität ist eine der wesentlichen Aufgaben des Betriebssystems, und sie ist ziemlich komplex. Dabei ist die Organisation des Programmablaufs in Prozessen von entscheidender Bedeutung Das Prozess-Modell Ein Prozess ist im wesentlichen ein in Ausführung befindliches Programm. Das kann sogar das Betriebssystem selbst sein. Zu diesem Prozess gehört dann auch zu jedem Zeitpunkt (oder zu jedem Maschinenzyklus) die für den Zeitpunkt aktuelle Ablauf-Umgebung des Programms sowie weitere Kenndaten, welche das Programm insgesamt betreffen. Zur statischen Information gehören z. B. der Bedarf an Betriebsmitteln wie Speicherplatz und periphere Geräte. Der registrierte Bedarf an verbrauchter CPU-Zeit ist dagegen ein statischer Parameter. Zu den dynamischen Parametern gehören der Zustand des Programmzählers und der Register, der aktuell belegte Speicherbereich und der momentane Wert von Variablen. Prozeß CPU-Register MMU-Register Datei - Info Zugriffsrechte Kernel-Stack Prozeß-Kontext Daten Programm Stack Abb. 2.1: Prozess-Daten Man kann vereinfacht annehmen, dass jeder Prozess seinen eigenen virtuellen Prozessor benutzt und darauf abläuft. Tatsächlich wird der Prozessor zwischen den Prozessen hin- und hergeschaltet, es findet ein quasi-paralleler Betrieb statt. Eine solche Betriebsart wird als Mehrprogrammbetrieb bezeichnet. Ein Prozess kann als Eltern-Prozess selbst wieder ein oder mehrere Kind-Prozesse erzeugen. Tatsächlich kann ein eingelesenes und gestartetes Programm (Job) durchaus mehrere Prozesse erzeugen. 1

2 Prozeß D C B A passiv aktiver Prozeß Abb. 2.2: Mehrprogrammbetrieb t Jeder Prozess besitzt seinen eigenen, von den anderen unabhängigen Programmzähler. In normalen Betriebssystemen hat das zeitliche Nebeneinander mehrerer Prozesse einige für die Praxis wichtige unangenehme Auswirkungen: Wir nehmen an, dass ein Prozess A an einer Stelle angekommen ist, wo Daten vom Magnetband geholt und gelesen werden müssen. Die Zeit, die benötigt wird, bis das Magnetband eingelegt ist und seine Lesegeschwindigkeit genutzt hat, wird für einen andern Prozess benutzt. Dieser kann seinerseits aber nicht unbedingt genau dann verlassen werden, wenn die benötigten Daten am Lesekopf des Bandes vorbeirauschen. Dann wird möglicherweise erst zurückgespult und dann erneut gelesen, wobei der zwischendurch mehrere Umschaltungen zwischen verschiedenen Prozessen erfolgt sein können. Damit soll angedeutet sein, dass man oft nicht garantieren kann, dass ein Prozess zu einem bestimmten Zeitpunkt zu einem bestimmten Punkt oder Ereignis gekommen ist! Dies mag für einen PC, der mit Microsoft Office läuft, z. B. noch zumutbar sein, sicher aber nicht mehr für den Prozessor, der bei einem Auto die Bremskraft beim Antiblockiersystem steuert. Deshalb gibt es für solche Anwendungen spezielle Realzeit-Betriebssysteme. Wichtig ist, dass in einem Rechner mit einem Prozessor (ein-prozessorsystem) stets nur ein Prozess aktiv ist und CPU-Leistung erhält. In der Regel unterstützt dabei die CPU das Betriebssystem so weit, dass alle aktuellen Daten für den jeweilig aktiven Prozess in CPU-Registern gehalten und beständig aktualisiert werden. Prozess-Hierarchien Wir haben bereits bei der Einführung Prozess-Hierarchien betrachtet. Bei den meisten Betriebssystemen ist es möglich, dass ein Prozess einen oder mehrere neue kreiert (Kind-Prozesse), die wiederum Kinder haben können. Auf diese Weise entstehen Prozess-Hierarchien. Mit dem FORK-Aufruf in UNIX wird aus einem Vater-Prozess ein identischer Kind-Prozess erzeugt. Beide Prozesse bleiben aktiv. Dagegen wird in MS-DOS nach der Generierung eines Kind-Prozesses der Vater zur Ruhe gelegt und erst wieder aktiv, wenn der Kind-Prozess beendet ist. Prozess-Zustände Trotz der relativen Unabhängigkeit mehrere Prozesse voneinander müssen diese doch miteinander agieren. 2

3 Mit dem UNIX-Kommando cat chapter1 chapter2 chapter 3 grep tree werden die drei Dateien chapter1, chapter2, chapter3 hintereinandergehängt, und dann werden alle Zeilen ausgesucht, die das Wort "tree" enthalten. Wir haben also hier eine Verknüpfung zweier Prozesse. Es kann nun sein, dass ein Prozess den anderen überholt, also z. B. der mit dem grep- Befehl auf Daten warten muss, die cat noch nicht geliefert hat. Dazu muss grep vorübergehend blockiert werden. Deshalb gibt es verschiedene Zustände von Prozessen: rechnend (der Prozessor ist dem Prozess zugeteilt) rechenbereit (der Prozess ist ausführbar, aber der Prozessor ist einem anderen Prozess zugeteilt) blockiert (der Prozess ist ausführbar) rechnend 2 blockiert rechenbereit 1. Prozeß wartet blockiert auf Eingabe 2. Scheduler wählt einen anderen Prozeß aus 3. Scheduler wählt diesen Prozeß aus 4. Eingabe ist verfügbar Abb. 2.3: Prozess-Zustände und -Übergänge Für diese drei möglichen Zustände von Prozessoren sind also insgesamt vier Zustände definiert und sinnvoll möglich. Man könnte noch zwei weitere Quasi-Zustände hinzufügen: Nicht-existierend vor dem Start und nicht-mehr-existierend nach Beendigung. Dafür, dass ein Prozess in einen nicht-aktiven Zustand gerät, kann es mehrere Gründe geben. Er kann darauf warten, dass er Rechenzeit zugeteilt erhält (Bereit-Zustand) er eine Nachricht von einem anderen Prozess erhält (blockiert) er ein Signal von einem Zeitgeberbaustein (Timer) erhält (blockiert) er Daten eines Ein- / Ausgabegerätes erhält (blockiert) Prozesse, welche in den Bereit-Zustand geraten, werden in eine Warteschlange (ready-queue) eingefügt. Der in Abb. 2.3 beschrieben Ablauf bezieht sich sowohl auf Prozesse aus Nutzerprogrammen als auch auf Prozesse aus dem Betriebssystem selbst. Man kann nun den Ablauf prinzipiell so organisieren, dass nur jeweils ein abgearbeiteter Prozess den nächsten aufruft. Dann würde aber sowohl ein extrem langlaufender Prozess, z. B. durch ein Programm mit Endlos-Schleifen den ganzen Rechner blockieren (siehe DOS und Windows!). 3

4 Viel günstiger ist eine Betriebssystem-Funktion, welche Prozesse nach intelligenten Kriterien aktiviert und wieder deaktiviert. Von wesentlicher Bedeutung ist deshalb der Scheduler. Das ist ein relativ kleines Programm, das die Prozesse aufruft und verwaltet. Die unterste Schicht eines Betriebssystems ist also darstellbar als ein Scheduler und die darüberliegenden, von ihm verwalteten Prozesse. Der Scheduler ist also für die zeitliche Ablauf-Planung verantwortlich. Er ist in der Regel für den Nutzer nicht sichtbar oder gar steuerbar. 0 1 n-2 n-1 Scheduler Abb. 2.4: Unterste Schicht eines Betriebssystems Für alle möglichen Prozess-Zustände gibt es jeweils eine oder mehrere Listen, in welche die Prozesse (mit ihrer Prozess-ID-Nummer) eingetragen werden. Natürlich kann ein Prozess immer nur in einer Liste auftauchen Implementierung von Prozessen Bisher wurde nichts darüber ausgesagt, wie denn Prozesse tatsächlich technisch erzeugt und behandelt werden. Zunächst erzeugt und führt das Betriebssystem eine Liste der erzeugten und noch nicht wieder gelöschten, also aktiven und inaktiven Prozesse. Für jeden Prozess existiert ein Eintrag in diese Prozess-Tabelle, welche enthält: Programmzähler Stack-Zeiger (stack-pointer) den belegten Speicher den Zustand geöffneter Dateien Abrechnungs- und Scheduling-Information ggf. weitere Information, wie Register-Zuordnung und -Inhalte Die tatsächliche Form dieser Tabelle ist zwischen den Betriebssystemen unterschiedlich. Prozeßverwaltung Speicherverwaltung Dateiverwaltung Register Programmzähler Programmstatuswort Stack-Pointer Prozeßzustand Proßerzeugungszeit verbr. Prozessorzeit Proß.-Zeit Kindprozeß Zeitpunkt für Alarm Zeiger auf Infos unbearbeitete Signale Prozeßnummer verschiedene Anz.-Bits Zeiger auf Textsegment Zeiger auf Datensegment Zeiger auf BSS-Segment Terminierungsstatus Signalstatus Prozeßnummer Elternprozeß Prozeßgruppe reale UID effektive UID reale GID Bit-Maske für Signale verschiedene Anzeige-Bits UMASK-Maske Wurzelverzeichnis aktuelles Verzeichnis Dateideskriptoren effektive UID effektive GID Systemaufruf-Parameter verschiedene Anzeige- Bits Abb. 2.4: Typische Einträge in eine Prozess-Tabelle (UNIX) Die aktuellen Zustandsdaten der Hardware, mit denen der Prozess arbeitet, werden auch als Prozess- Kontext bezeichnet. Diese Daten betreffen Zustand und Register-Inhalte der CPU, einer ev. angeschlossenen Floating-Point-Einheit und der Memory-Management-Unit (MMU). 4

5 Einen Teil der Daten, welche den Zustand eines blockierten Prozesses einschließlich der Prozessor- Register beschreiben, kann man als einen "virtuellen Prozessor auffassen. Diese Daten-Basis muss bei einem Umschalten zwischen Prozessen jeweils neu geladen werden (Context-Switch). Die Einträge in die Prozess-Tabelle sind unter anderem notwendig, um die quasi-nebenläufige Abarbeitung mehrerer Prozesse zu organisieren. So ist z. B. jeder Klasse von I/O-Geräten (Diskettenlaufwerk, Festplatten, Stoppuhren, Terminals) ein eigener sogenannter Unterbrechungsvektor zugeordnet, der einen bestimmten Bereich des Arbeitsspeichers beansprucht. Er enthält die Adresse einer Unterbrechungs-Behandlungsroutine. Wir nehmen als Beispiel an, dass ein laufender Prozess deshalb unterbrochen wird, weil eine Festplatte eine Unterbrechungsmeldung (interrupt) an das Betriebssystem schickt. Die für die Interrupt-Bearbeitung zuständige Hardware legt den Programmzähler, das Programm-Statuswort und ggf. Register-Inhalte auf einen Stack. Dann setzt der Computer die Befehlsbearbeitung an einer Stelle fest, die der Unterbrechungsvektor für die Festplatte enthält. Jede weitere Bearbeitung ist dann Aufgabe des Betriebssystems. Zunächst muss die Unterbrechungs-Behandlungsroutine die Register-Inhalte sichern, die Prozess- Tabelleneintrag vorhanden sind. Die Nummer des aktuellen Prozesses und ein Verweis auf den dazugehörigen Eintrag werden als globale Variable gespeichert. Wenn das Betriebssystem die Rettungsaktion abgeschlossen hat, dann können die von der Hardware auf den Stack geretteten Informationen entfernt werden. Dann wird der Stack-Zeiger (Stackpointer) auf die Stack-Adresse umgesetzt, die von der Prozess-Verwaltung benutzt wird. Routinen zur Rettung bestimmter Register-Inhalte oder zum Umsetzen des Stack-Pointers sind in der Regel nicht in einer Hochsprache (wie C) ausdrückbar, sondern sind als Assembler-Routinen implementiert. Die komplexeren Routinen für die Verarbeitung des Interrupts sind dagegen z. B. in C implementiert. Als nächste Aktion ist dann der Prozess auszumachen, der den Interrupt des Platten-Controllers ausgelöste hat. Dieser Prozess wird sich zwischendurch "zur Ruhe begeben" haben. Dieser Prozess wird nun von "blockiert" auf "rechenbereit" gesetzt. Der Scheduler wird gestartet. Um dann festzustellen, welcher Prozess ausgeführt werden soll, muss der Scheduler aktiviert werden. Dieser muss nun feststellen, welcher Prozess als nächster ausgeführt wird. Das kann sowohl der Prozess sein, der die Platten-Aktion gestartet hat, als auch der unterbrochene Prozess sein. In UNIX haben I/O-Prozesse Vorrang, werden also zuerst ausgeführt, damit sie die nächste vorliegende I/O-Anfrage schnell starten können. Mit dieser Strategie wird effektiv der Parallelitätsgrad erhöht, da laufende I/O-Prozesse fast immer noch Betriebspausen möglich machen (z. B. bis zum Auffinden einer bestimmten Adresse auf der Platte), die wiederum anderweitig nutzbar sind. Wenn der Prozess ausgewählt ist, kommt wieder die grundlegende Assembler-Routine zum Zuge, welche die Register lädt und die Seitentabelle für den zu startenden sucht und den Prozess startet. Für die Unterbrechungsbehandlung und das Scheduling lässt sich folgende Tabelle angeben: Tab. 1: Ausführungsschritte des Betriebssystems bei einer Unterbrechung 1. HW sichert PC auf Stack 2. HW lädt PC aus Interrupt-Vektor 3. Assembler-Routine rettet Register-Inhalte 4. Assembler-Routine bereitet neuen Stack vor 5. C-Prozedur markiert Prozeß als rechenbereit 6. Scheduler bestimmt nächsten Prozeß 7. C-Prozedur gibt Kontrolle an Assembler-Routine 8. Assembler-Routine startet aktuellen Prozeß 5

6 Der Context-Switch ist eine relativ aufwendige Prozedur. Wenn der Scheduler sehr häufig einen Context-Switch veranlasst, so wird das erhebliche negative Auswirkungen auf die netto verfügbare Rechnerleistung zur Folge haben. Ganz unterschiedlich zwischen den verschiedenen Betriebsystemen ist die Anzahl der verschiedenen Ereignisse, auf die gewartet werden kann, und die Anzahl und Typen der verfügbaren Warteschlangen. Das hängt auch damit zusammen, dass die verschiedenen Betriebssysteme auch unterschiedliche Strategien für das Erzeugen und Terminieren von Prozessen so wie die Zuteilung von Rechenleistung und die Einordnung in Wartelisten verfolgen. Im Detail unterscheiden die Betriebssystem-Menschen sogar noch zwischen der Planung für die Zuteilung von Betriebsmitteln (Scheduling) und der tatsächlichen Zuteilung (Dispatching) Prozesse in UNIX Bei UNIX gibt es sogar insgesamt 6 verschiedene Zustände von Prozessen. Die Zustände running (SRUN), blocked (SSLEEP) und ready (SWAIT) entsprechen denen im einfachen Schema. Der Zustand stopped (SSTOP) bezieht sich auf hierarchische Prozess-Bäume und wird von einem Kind- Prozess eingenommen, der auf ein Signal des Eltern-Prozesses wartet. Darüber hinaus existieren noch die Zwischenzustände idle (SIDL) und zombi (SZOMB), die für die Erzeugung und Terminierung von Prozessen benötigt werden. blockiert erzeugt erhalte Signal warte auf Ereignis terminiert nicht-ex idle bereit weitermachen Zuteilung stop aktiv zombi nicht-ex. warte auf Eltern Abb. 2.5: UNIX-Zustände und Zustandsübergänge Der Übergang von einem Zustand zum anderen erfolgt wiederum über Systemaufrufe. Ist der fork ( ) Aufruf erfolgt, so erzeugt zunächst der aufrufende Prozess eine Kopie von sich selbst und hängt diese in die ready-liste. Nun existieren zwei nahezu identische Kopien desselben Prozesses. Der einzige Unterschied liegt im Rückgabewert der Funktion: Während der Eltern-Prozess die enthält die Prozess-Identifizierungs-Nummer (PID) des Kindes, dagegen enthält das Kind den Wert PID = 0. Genau daran ist sichtbar, dass es ein Kind-Prozess ist. Eltern PID = fork ( ) /* PID # 0 */ if (PID ==0) {exec }; waitpid(pid) Kind / * PID == 0 */ if (PID == 0) {exec ( program ).... exit( ) }; Abb. 2.6: Prozess-Erzeugung und -Beendigung in UNIX 6

7 Dann werden im Kind-Prozess alle Zeiger und Variablen initialisiert und, wenn z. B. der Start mit exec program gestartet werden soll, das zu startende Programm mit Code aus der Datei program gefüllt. Der Programm-Zähler erhält die Anfangsadresse für den Programm-Code im Speicher. Schließlich wird der fertige Kind-Prozess in die ready-liste eingefügt. Der Eltern-Prozess wartet mit einem Statement wait (PID) bis der Kind-Prozess zu einem exit- Statement gekommen ist und sich damit quasi selbst beendet. In Unix stammen alle Prozesse von einem einzigen Ur-Prozess, dem sogenannten Unit-Prozess mit der PID = 1 ab. Wir ein Kind-Prozess beendet und findet sich dann kein Eltern-Prozess mehr, so wird statt dessen Unit benachrichtigt und gestartet. In dem Zeitraum, der zwischen der Erreichen des exit-statements im Kind-Prozess und dem Akzeptieren beim Eltern-Prozess vergeht, gerät der Kind- Prozess in dem Zombie-Zustand. Der interne Prozess-Kontext ist bei UNIX in zwei Teile gespalten: Der Prozess-Kontrollblock (PCB) steht als Speicher-residente Tabelle (process table) im Arbeitsspeicher. Ein zweiter Block, die "user structure wird nur dann benötigt, wenn der Prozess aktiv ist. Er kann deshalb mit dem übrigen Code auf den Massenspeicher ausgelagert werden, wenn ein Prozess blockiert oder gestoppt ist. Man unterscheidet also a) im Speicher-residenten Teil die Prozess-Kontrollblöcke (PCB): Scheduling-Parameter für die Rechenzeit-Vergabe durch den Scheduler Speicher-Referenzen: Code-, Daten-, und Stack-Adressen im Hauptspeicher und im Plattenspeicher Signaldaten: Maske, Zustände Prozess-Zustand, erwartete Ereignisse, Timer, PID, PID der Eltern, User/Gruppen-Ids b) auslagerbarer Benutzer-Kontext (swappable user architecture) Prozessor-Zustand: Register, Register der FPU, weitere lebenswichtige Register-Inhalte Systemaufruf: Parameter, vorhandene Ergebnisse Datei-Info-Tabelle (file descriptor table) Benutzungsinformationen: CPU-Zeit, max. Stack-Größe Kernel-Stack: Stack-Lokation für Systemaufrufe des Prozesses Die Speicher-residente PCB (process control block) ist für einen Prozess nur indirekt über Systemaufrufe für Abfragen und Änderungen zugänglich. Dagegen ist der Benutzer- Kontext über spezielle UNIX-Systemaufrufe durchaus direkt ansprechbar und modifizierbar Prozesse in Windows NT Windows NT musste verschiedene Arten von Prozessen unterstützen, um den anfänglichen Anforderungen an Kompatibilität zu genügen. Man hat deshalb nur für eine einzige, möglichst allgemeine Art von Prozessen ein Prozess-Steuerungssystem geschaffen. Diese Art von Prozessen wird als "thread objects bezeichnet. 7

8 trans. erzeugt erhalte Signal warte auf Ereignis terminiert nicht-ex init ready ausgewählt, abgebrochen Abbruch standby running termin nicht-ex. dispatch Abb. 2.7: Prozess-Zustände im Windows NT Die speziellen Eigenschaften von OS/2-Objekten, POSIX-Objekten und Windows32 - Objekten hat man möglichst verborgen und gekapselt. Sie spielen dann bei Zustandsänderungen keine Rolle mehr. Der oben dargestellte Graph ist vereinfacht. Zur Erzeugung von Prozessen gibt es nur einen Systemaufruf NTCreateProcess( ). Bei diesem kann auch der Eltern-Prozess explizit angegeben werden. Andere, Subsystem-spezifische Aufrufvarianten werden auf diesen Aufruf zurückgeführt. In POSIX gibt es einen speziellen POSIX-fork ( )-Mechanismus. Ein POSIX-Programm bzw. ein POSIX-Prozess ruft den fork ( )-Befehl auf. Dieser wird in eine Nachricht umgewandelt und über das POSIX-Subsystem an den Kern geschickt. Dieser Vorgang ruft dann NtCreateProcess ( ) auf und gibt als Eltern-PID die des POSIX-Programmes an. Danach verwaltet das POSIX-Subsystem den Vorgang weiter durch vom Kern zurückgegebene sogenannte Objekt-Schlüssel (object handle). Alle System-Aufrufe vom POSIX-Prozess aus landen zunächst beim POSIX-Subsystem, dieses erzeugt NT-Systemaufrufe, die Ergebnisse werden im POSIX-Format an den jeweils aufrufenden POSIX-Prozess zurückgegeben. Mit anderen Subsystemen verfährt Windows NT ähnlich Leichtgewichtsprozesse (Threads) Man sollte bisher schon den Eindruck mitgenommen haben, dass der für die Administration von Prozessen notwendige Aufwand und damit auch der zugehörige Speicherplatz ganz erheblich ist. Neben Daten wie Prozess-Nummer (PID) und CPU-Daten sind dort auch Angaben über geöffnete Dateien, den logischen Status von Ein- und Ausgabe-Geräten sowie der Programm-Code und seine Daten abgelegt. Das wird in manchen Fällen durchaus mehr sein, als in den Hauptspeicher passt. Bei einem Prozess-Wechsel werden dann jeweils recht viele Speicherblöcke zwischen Platte und Hauptspeicher hin- und her bewegt werden müssen. Oft benötigt man aber beim Prozess-Umschalten keine völlig neuen Prozesse, sondern nur unabhängige Stücke von Code, die von extern in einen Prozess eingebunden werden müssen. Das könnte z. B. dann der Fall sein, wenn ein Anwenderprogramm etwa die Bibliotheksfunktion aufruft, die die Berechnung der Cosinus-Funktion liefert. Ein voller Prozess-Wechsel ist dann nicht notwendig. In solchen Fällen spricht man dann auch von Co-Routinen. Oft sind komplexe Programme tatsächlich aus einer Vielzahl ziemlich unabhängig voneinander ablaufender Routinen aufgebaut. Die Verwendung solcher threads legt nun nahe, innerhalb eines großen Prozesses ein weiteres Prozess-System aus Leichtgewichtsprozessen (LWP) zu schaffen. Im einfachsten Fall sorgt man dafür, dass sich dann die einzelnen Routinen jeweils gegenseitig die Kontrolle übergeben. Dann muss man aber auch eine Verwaltung der Prozess-IDs dieser Prozesse und die jeweilige geordnete Übergabe organisieren. Das wird mit steigender Anzahl der sich gegenseitig abwechselnden Leicht-Prozesse zunehmend schwierig. Deshalb wird in manchen Betriebssystemen auch hier ein Scheduler eingeführt, welcher eine Bereit-Liste bedient. 8

9 Solche Vorgänge kann man entweder bereits auf der Anwender-Seite programmieren oder ins Betriebssystem integrieren. Wenn Systemaufrufe bedient werden müssen, so werden durch deren Umschaltzeiten die Threads etwas schwergewichtiger. Auch bei Leichtgewichtsprozessen gilt die Grundregel, dass jeder Prozess seine Daten unabhängig von anderen halten muss. Selbst dann, wenn solche Leichtgewichtsprozesse ihre Daten und ihren virtuellen Adressraum mit anderen Programmen teilen, ist eine Trennung notwendig. Organisiert wird dies meistens über einen Stack (= Stapelspeicher), in dem für jeden Prozess extra Platz bei der Erzeugung reserviert wird. Im Unterschied zu den echten "schweren Prozessoren benötigen Leichtgewichtsprozessoren viel weniger Kontext-Dateien, die bei jedem Umschalten aktualisiert werden müssen. Zu den wenigen zählen das Prozessor-Statuswort (PS) und der Stack-Pointer (SP). Auch den Programmzähler (PC) kann man im Stack ablegen. Mittels effizienter Implementierungen in Assembler-Sprache kann man so sehr schnelle Prozess- Systeme erhalten. 2.2 Ablaufplanung (Scheduling) Einführung Die Organisation des zeitlichen Ablaufs komplexer Vorgänge ist ein allgemeines Problem der Rechnerei und der Informationstechnik von großer praktischer Bedeutung. Scheduling-Probleme treten immer dann auf, wenn man mehr oder weniger parallel auftretende Vorgänge in eine sequentielle Reihenfolge bringen muss. Dazu gehören beispielsweise auch die Ankunfts- und Abflugpläne auf Flughäfen und die Fahrpläne der DB AG. Meistens lässt sich das ganze Problem in ein grobes, vorweg vorgenommenes Langzeit-Scheduling und ein detailliertes Kurzzeit-Scheduling gliedern. Das grobe Scheduling wird typischerweise vorab und off-line durchgeführt, wie z. B. durch den Fahrplan. Wenn aber dynamisch und unterwegs festgestellt wird, dass sich Änderungen ergeben (z. B. weil 2 Züge durch spielende Kinder Verspätungen erfahren haben und damit 6 Züge gleichzeitig in Berlin-Zoo ankommen, wo es nur 4 Gleise gibt), dann wird ein korrigierendes Kurzzeit-Scheduling notwendig. In der Rechnerei betrifft das Langzeit-Scheduling das Planen der Job-Ausführung, wenn z. B. eine Warteschlange von Batch-Jobs vorliegt. Das sind Rechenjobs, die ohne direkte interaktive Einwirkung von Nutzern abgearbeitet werden können. Auch für den interaktiven Betrieb gibt es dort spezielle Verfahrensweisen: Man wird z. B. auf einem Rechner nur eine bestimmte maximale Anzahl von Nutzern zulassen. Log-ins werden nur zugelassen, wenn momentan weniger als die maximale interaktive Last vorhanden ist. Auch bezüglich des Zuganges zu Servern in Rechner-Netzen werden solche Mechanismen verwendet. Jobende Nutzer Langzeit- Schedule Kurzzeitschedule Abb. 2.8: Langzeit- und Kurzzeit-Scheduling 9

10 Das Kurzzeit-Scheduling verteilt dagegen die Ressource "Prozessor-Leistung" auf die vorhandenen Prozesse. Da diese Vorgänge dynamisch ablaufen, ist hier sicherlich der größere Aufwand zu leisten. Die Entwicklung von optimalen Scheduling-Strategien für unterschiedliche Aufgaben hat in der Vergangenheit ganze Kompanien von Forschern beschäftigt Ziele und Zielkonflikte In der Vergangenheit war bei Rechnern oft die verfügbare CPU-Leistung der eigentliche Engpass. Man war deshalb versucht, die CPU möglichst optimal auszulasten. Das Ziel einer 100%-igen CPU- Auslastung war kaum je zu erreichen, aber waren im Batch-Betrieb möglich. Interaktiv wird man kaum je mehr als ca. 40% erreichen. Ein weiteres Ziel ist der möglichst hohe Durchsatz von Jobs. Dabei sollte aber im Sinn einer fairen Behandlung kein Job gegenüber einem anderen eindeutig vorgezogen werden. Natürlich sollte außerdem die Ausführungszeiten für die Jobs im Mittel auch möglichst gering sein, d. h. kein Job sollte länger als notwendig in Warteschlangen verbringen. Für den interaktiven Betrieb sollte die Antwortzeit auf Kommandos des Benutzers möglichst kurz sein. Diese Liste der Vorgaben ist nicht komplett und auf einen Multi-User-Rechner mit Batch-Betrieb ausgerichtet. Rechner, die on-line Aufgaben von Steuerung und Regelung übernehmen, müssen unter Echtzeit-Bedingungen nach ganz anderen Kriterien "gescheduled" werden. Schon beim "normalen" Rechner gibt es aber ganz unterschiedliche Aspekte. Jeder Prozess-Wechsel erfordert einen Austausch des Prozess-Kontext (context-switch) und kostet damit selbst wiederum Rechenzeit. Werden kurze Prozesse bevorzugt, so verkürzt sich zwar die Antwortzeit mit der Ablaufzeit zwischen zwei Eingaben und der Durchsatz steigt an. Andererseits werden die langen Prozesse benachteiligt und damit wird die Fairness verletzt. Wird die Auslastung erhöht, so verlängern sich die Antwortzeiten bei interaktivem Betrieb. Für einen optimalen Betrieb unter allen Bedingungen ist es günstig, die Scheduling-Mechanismen, also die Werkzeuge, von den Scheduling-Strategien zu trennen. Man sollte als Programmierer also auf der einen Seite über genormte Schnittstellen die Scheduling- Werkzeuge einfach benutzen können, andererseits sollte es möglich sein, dass der Programmierer oder sogar der Benutzer die Scheduling-Strategie bestimmt Nicht-preemptives Scheduling In einfachen Arbeitsumgebungen (wie z. B. dem Single-User-Arbeitsplatz am PC) ist es sinnvoll, einen Prozess so lange laufen zu lassen, bis er entweder beendet ist oder durch Randbedingungen (wie das Warten auf externe Daten) gestoppt wird. Auch bei einer Datenbank, wo vorab genau bekannt ist, wie lange eine Transaktion dauert, macht das Sinn. Ein solches Scheduling heißt "non-preemptive", also nicht vorzeitig unterbrochen. Dazu existieren wiederum mehrere Strategien: First Come - First Serve (FCFS) Die Prozesse werden in der Reihenfolge ihres Eintreffens in der Warteschlange einsortiert. Damit werden dann alle Tasks bedient, egal wie viel Zeit sie im einzelnen brauchen. Diese Strategie ist einfach über einen FIFO-Speicher zu realisieren. Man erhält bezüglich der mittleren Ausführungszeit damit allerdings keine sehr guten Ergebnisse, da gerade die kurzen Jobs möglicherweise sehr lange warten müssen. Shortest Job First (SJF) 10

11 Wenn man eine für eingegebene Jobs abschätzungsweise den voraussichtlichen Bedarf an CPU-Zeit kennt, dann wird man bei dieser Strategie den kürzesten Job vorziehen. Insbesondere werden von einer solchen Arbeitsweise die interaktiven Jobs begünstigt. Man kann sogar zeigen, dann mit dieser Strategie die mittlere Wartezeit eines Jobs minimiert wird. Allerdings verhungern sehr lange Jobs mehr oder weniger. Highest Response Ratio Next (HRN) Dabei werden Jobs mit großem Verhältnis Antwortzeit / Bedienzeit bevorzugt bearbeitet. Für Antwortzeit und Bedienzeit werden zunächst Schätzwerte eingesetzt. Zunächst werden Jobs mit kurzer Antwortzeit bevorzugt. Bei den liegengelassenen potentiellen Langläufern wächst aber auch die Antwortzeit um die schon ausgesessene Wartezeit, so dass die endlich auch drankommen. Priority Scheduling Hier wird zunächst jedem Prozess vorab eine Priorität verliehen. Entsprechend der Priorität wird der Prozess in die Warteschlange einsortiert. Innerhalb einer Gruppe von Prozessen mit derselben Priorität entscheidet dann eine andere Strategie, z. B. FCFS. Auch hier ergibt sich wieder das Problem, dass benachteiligte Jobs verhungern können. Dieser Effekt ist nur dadurch behebbar, dass man im Laufe der Zeit bei solchen benachteiligten Prozessen die Priorität automatisch heraufsetzt. Von den oben benannten Scheduling-Verfahren sind insbesondere SJF und HRN nur dann durchführbar, wenn man vorab gewisse Charakteristika der betroffenen Prozesse wie z. B. die voraussichtliche Ausführungszeit kennt. Nun kann aber die Ausführungszeit durchaus sehr stark schwanken, weil nämlich der Kontrollfluss in Programmen durchaus von Daten abhängig sein kann. Für viele Anwendungen wird man deshalb die geschätzte Laufzeit für einen bestimmten, immer wiederkehrenden Job dynamisch den Verhältnissen anpassen müssen. Wir nehmen an, dass der Parameter a eines Prozesses (oder Jobs) der Schätzwert für das Scheduling sein soll. Bei einem bestimmten Durchlauf des Jobs zu einem Zeitpunkt t hat man nun aber einen aktuellen Wert bt gemessen. Für die nächste Ausführung des Jobs zu einem Zeitpunkt (t + 1) wird man dann auch den Schätzwert anpassen und ein modifiziertes a(t+1) ansetzen. Dazu wird gebildet: a(t + 1) = (1 - a) a(t) + a bt Wenn man sich nun anschaut, wie sich diese Formel zu verschiedenen Zeiten auswirkt: a(0) = b0 a(1) = (1 - a) b0 + a b1 a(2) = (1 - a) 2 b0 + (1 - a) a b1 + a b2 a(3) = (1 - a) 3 b0 + (1 - a) 2 a b1 + (1 - a) a b2 + a b3 usw. 11

12 Wenn a<1 gewählt wird, so nimmt der Einfluss früherer Ereignisse nach dieser Formel exponentiell ab. Der Parameter altert also. Man hat hier in einfacher Form ein adaptives Verfahren vor sich. Mit der Wahl von a = 1/2 ist die Berechnung der Formel besonders einfach, weil man nämlich keine explizite Division braucht, sondern mit Bit-Shift-Operationen auskommt Preemptives Scheduling Wir haben bisher nur Scheduling-Verfahren kennengelernt, die nicht direkt in den Ablauf von Prozessen selbst eingreifen. Damit kann man auch nicht on-line umschalten, wenn etwa ein Prozess sich aufhängt und damit alle anderen blockiert. Es wird für einen effizienten und stabilen Betrieb also noch ein anderes Scheduling darunter benötigt, das die einzelnen Prozesse beeinflusst und laufende Jobs unterbrechbar macht. Prozess- Ankunft Scheduler Prozessor Abgang Abbruch Abb. 2.9: Pre-emptives Scheduling Eine grundlegende Strategie besteht darin, die Ressource "CPU-Zeit" in einzelne, gleich große Zeitscheiben aufzuteilen. Ein Prozess mit dem Status bereit wird jeweils in die Warteschlange einsortiert. Zu Beginn einer neuen Zeitscheibe wird jeweils der Dispatcher durch ein Zeit-Interrupt-Kommando aufgerufen. Dann wird der laufende Prozess unter Rettung aller Parameter abgebrochen und in die Warteschlange eingeordnet, z. B. an deren Ende. Der in der Warteschlange zuvorderst stehende bereite Prozess wird dagegen in den Speicher übernommen und aktiviert. Auch hier gibt es im Detail wieder unterschiedliche Strategien: Round Robin (RR) Innerhalb des Zeitscheiben-Verfahrens ist der FCFS wieder als einfachste Strategie implementierbar. Dann wird ein gestoppter Prozess jeweils wieder ans Ende der Warteschlange gerückt, die als einfacher FIFO-Speicher ausgebildet ist. Die Kombination des Zeitscheiben-Verfahrens mit der FCFS-Strategie wird auch als Round-Robin- Algorithmus bezeichnet. In der Praxis wird man hier ein Verhalten finden, das im Detail stark von der Länge der Zeitscheiben abhängt: a) im Verhältnis zu Zeitaufwand für einen Umschaltvorgang b) im Verhältnis zur Länge der Prozess-Laufzeiten Bei im Verhältnis zur Job-Länge sehr langen Zeitscheiben wird das Verhalten des einfachen FCFS- Algorithmus erzeugt. Wählt man dagegen sehr kleine Zeitscheiben, so wird aus einem Prozessor virtuell eine Überlagerung mehrere quasi-parallel arbeitender Maschinen. 12

13 Da ist an sich wünschenswert, funktioniert aber nur, wenn der Prozessor sehr schnell im Vergleich zum Speicher ist und wenn die Prozess-Umschaltung fast keine Zeit benötigt. Dazu benötigt man spezielle Hardware, die z. B. auf den CDC 6600 Rechnern vorhanden war. Rein per Software dauert eine Umschaltung leicht Mikrosekunden. Eine Maschine wird also im Extremfall nur noch umschalten und keine Netto-Prozessorleistung mehr erzeugen. Als Daumenregel wird man die Zeitscheiben größer machen als die mittlere CPU-Zeit, die zwischen 2 I/O-Vorgängen liegt. Man kommt dann auf etwa 100 Millisekunden. Dynamic Priority Round Robin (DPRR) Das RR-Scheduling kann man nochmals durch eine Art Vorstufe erweitern, indem man eine prioritätsgesteuerte Warteschlange für die Jobs vorschaltet. Die Priorität der zunächst wartenden Prozesse wächst zunächst nach jeder Zeitscheibe zunächst linear an, es erfolgt aber noch keine Bearbeitung. Wenn eine gewisse Schwelle überschritten ist, wird ein Prozess in das Round-Robin- Verfahren eingeschleust und in die Haupt-Warteschlange einsortiert. Shortest Remaining Time First Jetzt bedeutet die SJF-Strategie, dass jeweils aus einer Warteliste der Job in das Round-Robin- Verfahren eingebracht wird, der voraussichtlich die geringste benötigte CPU-Zeit hat Multiple Warteschlangen und multiple Scheduler Selbst ein modernes Ein-Prozessor-System wie ein PC hat eigentlich mehrere Prozessoren, die z. B. in den Controllern für die Ein- und Ausgabegeräte stecken. Damit wird es z. B. möglich, ohne direkte Inanspruchnahme Daten zwischen Arbeitsspeicher und dem Massenspeicher (Platte) oder von und zu den Puffern für Ein- Ausgabegeräte zu transportieren. Hauptprozessor I / O Festplatte 1 I / O Festplatte 2 I / O Terminals Abb. 2.10: Multiple Warteschlangen 13

14 Insbesondere wird der direkte Zugriff zum Arbeitsspeicher ohne Einschaltung des Hauptprozessors (direct mempry access, DMA) recht häufig verwendet. Dazu existiert in vielen Rechnern ein spezieller DMA-Controller, der auch als eigenes, vom Hauptprozessor unabhängiges Betriebsmittel betrachtet werden kann. Deshalb ist es sinnvoll, für jeden Ein-/Ausgabekanal eine eigene Warteschlange einzurichten, die vom DMA-Controller bedient wird. Damit hat der "Dispatcher", also das Programm, was die Jobs bzw. die Prozesse sozusagen "handwerklich" verteilt, im wesentlichen die jeweils aktuellen Jobs von einer Warteschlange in die nächste umzuhängen. Dazwischen liegen dann jeweils Phasen, in denen der Job CPU-Zeit bekommt (CPU-Bursts). Wenn man dann nicht nur eine Art von Jobs hat, sondern derer mehrere, dann muss für jeden Job- Typ jeweils eine eigene Warteschlange eingeführt werden. Man spricht dann auch von Multi-Level- Scheduling. Entsprechend den Prioritäten der Abarbeitung sind die Warteschlangen auch in einer bestimmten Reihenfolge angeordnet. Prio 0: Systemprozesse Prio 1: Interaktive Jobs Prio 2: Allgemeine Jobs Prio 3: Batch-Jobs Abb. 2.11: Multi-Level-Scheduling Können darüber hinaus Jobs auch noch nach längerer Wartezeit in eine Warteschlange höherer Ordnung überwechseln, dann spricht man von einem Mult-Feedback-Scheduling. Bisher nicht betrachtet wurde das Problem, dass nicht alle Prozesse gleichzeitig im Arbeitsspeicher vorrätig gehalten werden können. Um trotzdem den Scheduling-Prozess selbst im Hauptspeicher durchführen zu können, werden zumindest die wichtigsten Daten eines jeden Prozessors, zusammengefasst im Prozess-Kontroll-Block im Hauptspeicher gehalten, der Rest der Prozess- Information wird auf den Massenspeicher ausgelagert (Swapping). Wird ein Prozess aktiviert, dann muss die gesamte Datenbasis für den Prozess (mehr oder weniger) in den Hauptspeicher geladen werden (swapping), bevor eine Ausführung möglich ist. (Wir werden noch bei sogenannten virtuelle Betriebssystemen sehen, dass es doch nicht der ganze Prozess sein muss). Der Kontext-Wechsel kostet dann unverhältnismäßig viel Zeit. Es ist also eine Strategie zumindest sehr nützlich, die dafür sorgt, dass der Arbeitsspeicher (so er groß genug ist), immer die richtigen Prozesse auf Vorrat enthält. Benötigt wird dazu ein zweiter Scheduler, der nur für das Ein- und Auslagern verantwortlich ist. Dieser zweite Scheduler, der, wie wir sehen werden, auch für die Speicher-Verwaltung insgesamt von erheblicher Bedeutung ist, wird in größeren Abständen aufgerufen als der Kurzzeit-Scheduler. Beide Scheduler haben eigene Warteschlangen. 14

15 2.2.6 Scheduling für Echtzeit-Systeme und eingebettete Systeme Wir haben bisher nur einen bestimmten Typ von Rechner betrachtet, nämlich einen "General- Purpose"-Rechner im Multi-User / Multi-Tasking-Betrieb. Was dessen Aufgaben betrifft, so waren diese: nicht Realzeit-kritisch voneinander unabhängig lösbar. Diese Kriterien sind für Aufgaben der Steuerung und Regelung nicht erfüllt. Deshalb unterscheidet man "normale" oder "general-purpose"-rechner von Echtzeit-Systemen, bei denen andere Scheduling-Strategien benötigt werden. Man unterscheidet oft "Soft-Echtzeitsysteme", bei denen eine Verzögerung z. B. Unmut und Ärger des interaktiven Nutzers nach sich zieht, von "echten" Realzeit-Systemen, die z. B. in Fahrzeugen und Flugzeugen eingesetzt werden. Ein Rechner, der z. B. die Kraftstoff-Einspritzmenge eines Motors berechnet, muss (im Viertakt- Motor) alle 2 Umdrehungen der Kurbelwelle ein Ergebnis liefern. Typisch für solche Realzeit-Systeme, die oft in Form "eingebetteter" Systeme für die Steuerung und Regelung vorkommen, dass sich die Software nicht beliebig ändert, sondern nur selten geändert und modifiziert wird. Die Software für eine Diesel-Einspritzsteuerung wird oft genauso lange "leben" wie der Motor selbst. Die Scheduling-Strategien entsprechen dann oft denen, welche man beim Entwurf komplexer Hardware verwendet. Ein weiteres Beispiel aus der Technik ist die Fluglage-Steuerung (fly by wire). Der Steuerrechner benötigt dazu: alle 5 ms die aktuellen Beschleunigungswerte in x-, y- und z-richtung, alle 40 ms die Werte der Drehungen in die entsprechenden Richtungen jede Sekunde die aktuelle Außentemperatur alle 10 s die absolute Position des Flugzeugs. Daraus resultiert eine Aktualisierung der Monitor-Schirme jede Sekunde. Die wichtigsten Scheduling-Strategien für Echtzeit-Systeme sind: Polled Loop (Polling) Der Prozessor fragt periodisch externe Geräte bzw. die entsprechenden Schnittstellen ab, ob aktuelle Daten vorhanden sind. Wenn ja, werden diese sofort verarbeitet. Leider ist das System ineffizient, weil oft vergebliche Abfragen stattfinden. Es eignet sich auch nur für insgesamt wenige Geräte, da bei zeitkritischen Anwendungen sonst zu lange Pausen zwischen den Abfragen bei den einzelnen Geräten auftreten. Auch ist die Einrichtung von Puffer-Speichern für die ankommenden Daten notwendig. Interrupt-gesteuerte Systeme Der Prozessor führt als normale "task" eine Warteschleife aus. Treffen neue Daten ein, so löst das einen Service anfordernde Gerät einen Interrupt aus. Dann springt der Prozessor zu vordefinierten Interrupt-Service-Routinen (ISR). Zusätzlich muss man dann allerdings damit rechnen, dass während der Bearbeitung einer Interrupt-Routine schon wieder ein weiterer Interrupt auftritt. Deshalb muss 15

16 man wiederum Prioritäten der Interrupts gegeneinander einführen. Prozessor-Architekturen lassen oft auch unterbrechbare oder maskierbare und nicht-unterbrechbare Interrupts zu. Problematisch wird diese Strategie dann, wenn eine Häufung von Interrupts auftreten kann: Dann muss der Prozessor laufend zwischen verschiedenen Interrupts umschalten, was selbst wieder viel Rechenzeit kostet. Und Interrupts geringer Priorität, die lange warten müssen, können sogar von der nächsten Anforderung auf demselben Kanal überschrieben werden. Minimal Deadline First Dabei wird zunächst der Prozess angearbeitet, der die engste Zeitschranke (Deadline) TD aufweist. Diese Strategie funktioniert aber nur dann, wenn auch wirklich mehrere unterschiedliche Zeitschranken bestehen. Dagegen versagt das Verfahren, wenn mehrere Anwendungen mit gleichen Zeitschranken zu bedienen sind. Minimal Processing Time First Derjenige Prozess wird ausgewählt, der die minimale restliche Bedienzeit Tc besitzt. Dies entspricht der SJF (shortes job first)-strategie und kann bedeuten, dass ein kurzer Job mit niedriger Priorität einem langen Job mit hoher Priorität vorgezogen wird. Rate-Monotonic Scheduling (RMS) Zunächst sei ein Prioritätensystem mit festen Ausführungsraten der benötigten Tasks vorhanden und definiert. Es ist also bekannt, wie häufig bestimmte Tasks aufgerufen werden und wie lange der Ablauf jeweils dauert. Dann wird man die hohen Prioritäten den Tasks mit häufiger Ausführung und die niedrigen Prioritätsraten den Tasks mit niedriger Ausführungsrate zuordnen. Wenn ein zeitliches Ablaufschema unter diesen Voraussetzungen nicht gefunden werden kann, dann kann man beweisen, dass auch kein anderes mögliches Ablaufschema mit festen Prioritäten zum Erfolg führt. Bei einer CPU-Auslastung von 70% und darunter werden von RMS alle Zeitschranken garantiert eingehalten. Es kann dazu aber notwendig werden, dass die geringe Priorität einer wichtigen Task mit niedriger Ausführungsfrequenz angehoben werden muss. Foregroud-Background-Scheduling Typischerweise kann man auch in Echtzeit-Systemen zwischen absolut notwendigen Tasks auf der einen Seite und nützlichen, aber aufschiebbaren Tasks auf der anderen Seite unterscheiden. Beim Scheduling kann man also zwischen den extrem wichtigen Prozessen im Vordergrund (Foreground) und den aufschiebbaren Prozessen im Hintergrund (Background) unterscheiden. Zu den weniger zeitkritischen Funktionen zählen z. B.: eingebauter Selbsttest und Fehlerdiagnose RAM Scabbing: Auslesen, prüfen, ggf. korrigieren von RAM-Inhalten, um transiente Speicher- Fehler in den Griff zu bekommen Auslastungsmonitore und Watch-Dog-Timer: das sind Programme, bei denen in bestimmten Abständen Bits gesetzt oder umgesetzt werden müssen. Passiert das nicht, so ist ein Überlast-Fall oder ein Ausfall gegeben. Für ein typisches Realzeit-Betriebssystem kann man sogar drei Gruppen von Tasks unterscheiden: a) solche, die harte Realzeit-Anforderungen beinhalten b) solche, die nicht realzeitkritisch sind, aber doch irgendwann erledigt werden müssen c) solche, die nur wünschenswert aber nicht notwendig sind. 16

17 Für Systeme dieser Art wurden spezielle Scheduling-Strategien entwickelt, welche die Variablen Wichtigkeit, Zeitschranke T D und die benötigten Betriebsmittel berücksichtigen Scheduling in UNIX und in Windows NT UNIX verwendet grundsätzlich ein Round-Robin-Verfahren für die Zuteilung von Rechenzeit, das zusätzlich durch Prioritäten überlagert wird. Jeder Task wird eine anfängliche Priorität zugeteilt, die sich entsprechend den Wartezeiten nochmals erhöht. Damit besteht einerseits eine Bevorzugung der Systemprozesse, andererseits kommen auch Langläufer an die Reihe. Die Prioritäten werden durch ganze Zahlen dargestellt. Frühe UNIX-Versionen benutzten dazu die Zahlen -127 bis +127, wobei kleine Zahlen für hohe Prioritäten stehen. Negative Zahlen stehen für System-Prozesse, die normalerweise für User-Routinen nicht unterbrechbar sind. Es existiert sogar ein (sehr selten benutztes) Kommando nice, mit dem man als User eigene Tasks in der Priorität herabsetzen und damit nett zu anderen Nutzern sein kann. Natürlich können auch mehrere Jobs mit gleicher Priorität existieren. Dann gibt es für alle Jobs gleicher Priorität jeweils eine eigene FCFS-Warteschlange. Sind alle Jobs einer Warteschlange abgearbeitet, so wird die Schlange mit der nächst niedrigeren Priorität in Angriff genommen. Jobs, deren Priorität sich durch Wartezeiten erhöht, werden kontinuierlich in Schlangen mit höherer Priorität umgehängt. Man nennt das dann multi-level feedback scheduling. PCB prio 0 Realtime Variable Priorität System PCB # 1 # 2 # 3 # 4 #5 255 Abb. 2.12: Multi-Level-Warteschlangen in UNIX In neueren UNIX-Varianten reicht die Priorität von 0 bis 255 und ist zusätzlich unterteilt in Bereiche für Real-Time-Anwendungen, Systemroutinen und normale User. Die Warteschlangen bilden eine verkettete Liste. Die inhaltlichen Zeiger deuten auf die Prozess- Kontrollblöcke der Prozess-Tafel. Alle Tasks innerhalb der Prioritätsstufen für System-Routinen ( ) und für Nutzer ( ) werden nach dem Zeitscheiben-Verfahren zugeteilt. Eine dedizierte Klasse von Jobs, die mit dem speziellen System-Aufruf rtprio( ) gestartet werden, behandelt man extra. Ihre Priorität (0-127) ist von Beginn an höher und wird nicht mehr verändert. 17

18 Eine andere Eigenschaft neuerer UNIX-Varianten ist das pre-emptive Scheduling von Prozessen, die sich im Kernel-Modus befinden. Sie sind in der Regel nicht mehr unterbrechbar. Es gibt auch UNIX-Varianten speziell für den Echtzeit-Einsatz, die mit fest vereinbarten Speicher- Blöcken zur Vermeidung von Swapping-Effekten arbeiten. Auch Windows NT unterstützt ein Multi-Level-Scheduling, das Echzeit-Jobs ermöglicht. Die Prioritäten gehen von 0 (geringste, für den Leerlauf-Prozess) bis zu 31 für Echtzeit-Prozesse. Verwaltet werden allerdings nicht Jobs, sondern Leichtgewichtsprozesse (threads). Scheduling und Dispatch sind voneinander getrennt. prio 31 ready queue real time 16 variable 15 Priorität 14 System 1 0 idle - Leichtprozess Abb. 2.13: Dispatcher - Queue in Windows NT Der Dispatcher besitzt und unterhält eine eigene Datenbasis, die den Status der Threads und der CPU(s) festhält und auch den Scheduler versorgt. Windows NT teilt den threads nach einem pre-emptiven Zeitscheiben-Verfahren Rechenzeit zu. Nach jeder Zeitscheibe (timer interrupt) wird die Priorität des entsprechenden threads (1-15) etwas vermindert, bis schließlich die Basis-Priorität (2-6) erreicht ist. Dann wird entschieden, welcher der Threads in der Warteschlange die höchste Priorität hat und ob der Thread auf dem Prozessor ausgeführt werden kann. Dazu hat man eine neue Eigenschaft erfunden, die Prozessor-Affinität. Wenn ein Thread aus der Warteschlange in eine Bereit-Liste umgehängt wird, so erhält er eine zusätzliche Priorität, die von der Art der Warteliste abhängig ist. Terminal-I/O erhält z. B. mehr Priorität als Platten-I/O. Wird ein Thread bereit, der eine höhere Realzeit-Priorität (16-31) besitzt als ein gerade ausgeführter Thread, so wird dieser Thread in die Warteschlange eingereiht, und der Prozessor erhält einen Interrupt. Dieser schiebt dann den bisher bearbeiteten Thread zurück in die Warteschlange und wechselt zu dem mit der höheren Priorität. Die initialen Prioritäten werden nach der Art der Jobs zugeteilt, wobei interaktive Jobs wichtiger sind als allgemeine I/O-Jobs, diese sind wiederum wichtiger als Rechenjobs. 2.3 Prozess-Synchronisation Prozesse laufen typischerweise nicht nur unabhängig voneinander ab, sondern müssen häufig miteinander kommunizieren. Bei der Einführung wurde bereits ein Beispiel gezeigt, wo in einer Folge von Kommandos der UNIX-Shell die Ausgaben eines Prozesses direkt an einen zweiten weitergegeben werden, ohne dass dazu ein Interrupt gestartet werden muss. Es muss also Mechanismen der Inter-Prozess-Kommunikation geben (inter-process-communication, IPC). 18

19 Die Organisation eines Rechners so, dass mehrere Prozesse quasi-nebenläufig durchgeführt werden, bringt potentiell viele Vorteile, aber auch die Notwendigkeit, die Kommunikation von Prozesen miteinander zu organisieren. Und dabei treten mehr als genug kritische Fälle auf. In diesem Fall muss man Prozesse miteinander und gegeneinander synchronisieren Gemeinsamer Speicher-Zugriff In manchen Betriebssystemen benutzen mehrere Prozesse einen gemeinsamen Speicher. Dies kann entweder der Hauptspeicher des Rechners oder aber eine gemeinsam genutzte Datei sein. Als Beispiel ist sei der Spooler für einen Drucker betrachtet. Das ist ein spezieller Speicher-Bereich, in dem Anforderungen für den Drucker-Zugriff abgelegt werden. Entsprechend den Eigenschaften eines Drucker-Jobs (langsam, kann off-line abgearbeitet werden), werden Drucker-Jobs zumeist in einer speziellen "Schlange" abgelegt. Falls ein Prozess eine Datei ausdrucken möchte, so legt er den Namen in einem speziellen Spooler-Verzeichnis ab. Ein anderer Prozess, der Drucker-Dämon, prüft regelmäßig, ob dort auszudruckende Dateien abgelegt sind. Falls eine Datei gefunden wird, so erfolgt der Ausdruck und das Löschen des Eintrages aus dem Spooler- Verzeichnis. Spooler- Verzeichnis 4 5 abc Progr. c out = 4 Prozeß A 6 Progr. n Prozeß B 7 in = 7 Abb. 2.15: Konflikt beim Zugriff zweier Prozesse auf gemeinsam genutzten Speicher Das Spooler-Verzeichnis sei nun als beliebig groß angenommen. Die Einträge sind mit 0,1,2,3... durchnumeriert. Er sollen außerdem zwei für mehrere Prozesse gemeinsam nutzbare Variablen "out" und "in" existieren. "out" bezeichnet den als nächsten zu druckenden Eintrag, "in" verweist auf den nächsten freien Eintrag. Diese Variablen sind in einer Datei enthalten, auf die alle Prozesse zugreifen können. Nehmen wir nun an (Abb. 2.15), dass zu einem bestimmten Zeitpunkt die Einträge 0 bis 3 leer sind (weil bereits gedruckt), während die Einträge 4 bis 6 belegt sind, und zwar mit den Namen und Adressen von Dateien, die noch ausgedruckt werden müssen. Zunächst liest ein Prozess A die Variable "in" und speichert ihren Wert "7" als lokale Variable an anderer Stelle ab. Danach ruft der Scheduler einen anderen Prozess B auf und liest ebenfalls die Variable "in". Er speichert dann an dieser Stelle den Namen einer zu druckenden Datei ein und inkrementiert den Wert der Variablen "in" auf 8. Zunächst wird die im Eintrag an der Stelle 7 abgespeicherte Datei noch nicht gedruckt, in der Zwischenzeit wird wieder Prozess A aktiv. Er nimmt an, dass 7 noch frei ist und schreibt seinerseits eine zu druckende Datei hinein, überschreibt also den Eintrag vom Prozess B. Dessen Druck wird niemals ausgeführt. 19

20 Nun ist das Drucker-Verzeichnis in einem inkonsistenten Zustand, den aber der Drucker-Dämon nicht erkennen kann. Da das Verhalten des Systems stark davon abhängt, in welcher Reihenfolge die Lese- und Schreibzugriffe erfolgen, spricht man hier von zeitkritischen Abläufen (race-conditions). Race-conditions treten auch in digitaler Hardware auf und stellen dort ein großes Problem dar. In der Software muss man sie systematisch ausschalten, weil sonst Systeme mit nicht vorhersehbarem Verhalten auftreten können Kritische Bereiche Das obige Beispiel zeigt, dass die Benutzung von Variablen durch mehrere Prozesse organisiert werden muss, um Konflikte und Fehler auszuschließen. Es muss also eine Art wechselseitiger Ausschluss von Prozessen bezüglich der Benutzung von Variablen stattfinden. Zumeist werden sich Prozesse lediglich mit für die lokalen Variablen beschäftigen (außer gewissen Netzwerk-Programmen). Man kann dann auch annehmen, dass sich Programme in nicht-kritische (weil lokale) und kritische (weil mit Kommunikation verbundene) Bereiche aufteilen lassen. Wenn das möglich ist, dann werden Probleme dann auftreten, wenn zwei Prozesse gleichzeitig im kritischen Bereich ihres jeweiligen Programms ablaufen. Anders herum sollte es möglich sein, Konflikte zu verhindern, wenn man verhindern kann, dass mehrere Prozesse gleichzeitig im kritischen Zustand sind. Für diesen Fall würde man aber auch gleichzeitig verhindern können, dass zwei Prozesse überhaupt miteinander kommunizieren können. Eine brauchbare Kompromiss-Lösung muss vier Bedingungen erfüllen: 1. Zu jedem Zeitpunkt darf sich jeweils nur ein Prozess im kritischen Bereich befinden 2. Annahmen über Ausführungsgeschwindigkeit oder die Anzahl der Prozessoren sind nicht zulässig 3. Kein Prozess, der sich nicht im kritischen Bereich befindet, darf andere Prozessoren blockieren. 4. Für jeden Prozess muss die Wartezeit, die er ggf. gesperrt werden muss, um nicht in den kritischen Bereich einzutreten, endlich sein. Um diese Forderungen zu erfüllen, muss das Betriebssystem passende Formen der Prozess- Verwaltung implementiert haben Wechselseitiger Ausschluss Im einfachsten möglichen Fall wird man dann, wenn ein Prozess den kritischen Bereich erreicht hat, einfach die Möglichkeit der Unterbrechung (Interrupt) für alle anderen Prozesse sperren. Das klingt zunächst attraktiv, hat aber einige böse Haken: Wenn ein Nutzer allein die Interrupt-Behandlung des Rechners sperren kann, so muss dies zunächst konsequenterweise auch für komplexere Systeme mit mehreren Prozessoren gelten. Das wäre zunächst mal sehr ungünstig für die Systemleistung insgesamt. Es kann aber auch vorkommen, dass systembedingte Interrupt-Meldungen anfallen, die sofort bearbeitet werden müssen (Netzausfall, Überlauffehler etc.) Wie in der Vorlesung im 3. Semester besprochen wurde, kann es für einen Prozessor (insbesondere einen mit Pipeline-Architektur) beliebig schwer sein, bei bestimmten Kombinationen von Interrupts und Prozessor-Zuständen eine sichere Interrupt-Bearbeitung mit Wiederaufsetzen zu gewährleisten. Deshalb sind Sperren für Interrupts zu bestimmten Zeitpunkten durch den Prozessor selbst vernünftig. Alternativ sei eine Software-Lösung betrachtet. 20

CPU-Scheduling - Grundkonzepte

CPU-Scheduling - Grundkonzepte CPU-Scheduling - Grundkonzepte Sommersemester 2015 Seite 1 Gesamtüberblick 1. Einführung in Computersysteme 2. Entwicklung von Betriebssystemen 3. Architekturansätze 4. Interruptverarbeitung in Betriebssystemen

Mehr

Kap. 2. Prozesse. Version vom 05.10.2009. Kap. 2 - Inhalt. Definition Prozeßzustände Threads Scheduling Beispiele. Folie 2

Kap. 2. Prozesse. Version vom 05.10.2009. Kap. 2 - Inhalt. Definition Prozeßzustände Threads Scheduling Beispiele. Folie 2 Kap. 2 Prozesse Version vom 05.10.2009 Kap. 2 - Inhalt Definition Prozeßzustände Threads Scheduling Beispiele Folie 2 Definition I - Woraus bestehen Prozesse? Prozeß ist ein Programm in seiner Ausführung,

Mehr

Systeme I: Betriebssysteme Kapitel 7 Scheduling. Maren Bennewitz

Systeme I: Betriebssysteme Kapitel 7 Scheduling. Maren Bennewitz Systeme I: Betriebssysteme Kapitel 7 Scheduling Maren Bennewitz Version 23.01.2013 1 Inhalt Vorlesung Aufbau einfacher Rechner Überblick: Aufgabe, Historische Entwicklung, unterschiedliche Arten von Betriebssystemen

Mehr

Systeme 1. Kapitel 5. Scheduling

Systeme 1. Kapitel 5. Scheduling Systeme 1 Kapitel 5 Scheduling Scheduling Verteilung und Zuweisung von begrenzten Ressourcen an konkurrierende Prozesse Beispiel: -> Zeitablaufsteuerung Zwei Prozesse zur gleichen Zeit rechenbereit auf

Mehr

Dämon-Prozesse ( deamon )

Dämon-Prozesse ( deamon ) Prozesse unter UNIX - Prozessarten Interaktive Prozesse Shell-Prozesse arbeiten mit stdin ( Tastatur ) und stdout ( Bildschirm ) Dämon-Prozesse ( deamon ) arbeiten im Hintergrund ohne stdin und stdout

Mehr

Programme werden durch den Ablauf eines oder mehrerer Prozesse (engl.: process, task) von einem Rechner abgearbeitet.

Programme werden durch den Ablauf eines oder mehrerer Prozesse (engl.: process, task) von einem Rechner abgearbeitet. Prozessverwaltung Prozesse Programme werden durch den Ablauf eines oder mehrerer Prozesse (engl.: process, task) von einem Rechner abgearbeitet. Prozesse sind Abfolgen von Aktionen, die unter Kontrolle

Mehr

Betriebssysteme (BTS)

Betriebssysteme (BTS) 9.Vorlesung Betriebssysteme (BTS) Christian Baun cray@unix-ag.uni-kl.de Hochschule Mannheim Fakultät für Informatik Institut für Betriebssysteme 10.5.2007 Exkursion Die Exkursion wird am Freitag, den 18.5.2007

Mehr

B.5 Prozessverwaltung B.5. Prozessverwaltung. 2002 Prof. Dr. Rainer Manthey Informatik II 1

B.5 Prozessverwaltung B.5. Prozessverwaltung. 2002 Prof. Dr. Rainer Manthey Informatik II 1 Prozessverwaltung Prozessverwaltung 2002 Prof. Dr. Rainer Manthey Informatik II 1 Prozesse Programme werden durch den Ablauf eines oder mehrerer Prozesse (engl.: process, task) ) von einem Rechner abgearbeitet.

Mehr

Begriff: Scheduling Planung, Schedule Plan. Verplanung der CPU-Zeit an die Threads (bzw. Prozesse)

Begriff: Scheduling Planung, Schedule Plan. Verplanung der CPU-Zeit an die Threads (bzw. Prozesse) 5 CPU-Scheduling Im folgenden wird von Threads gesprochen. Bei Systemen, die keine Threads unterstützen, ist der einzige "Thread" eines Prozesses gemeint. Früher wurde dieser Thread synonym mit dem Begriff

Mehr

Scheduling. Prozess-Ablaufplanung. Prof. Dr. Margarita Esponda Freie Universität Berlin WS 2011/2012

Scheduling. Prozess-Ablaufplanung. Prof. Dr. Margarita Esponda Freie Universität Berlin WS 2011/2012 Scheduling Prozess-Ablaufplanung Prof. Dr. Margarita Esponda Freie Universität Berlin WS 2011/2012 Scheduler Der Scheduler ist ein besonders wichtiges Programmteil jedes Betriebssystems. Prozesse P 1 P

Mehr

Übung zu Grundlagen der Betriebssysteme. 7. Übung 27.11.2012

Übung zu Grundlagen der Betriebssysteme. 7. Übung 27.11.2012 Übung zu Grundlagen der Betriebssysteme 7. Übung 27.11.2012 Threads Thread (Faden des (Kontrollflusses)): ist ein sequentieller Abarbeitungsablauf (Kontrollfluss) innerhalb eines Prozesses. Umfasst ein

Mehr

Betriebssysteme I WS 2013/2014. Betriebssysteme / verteilte Systeme rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404

Betriebssysteme I WS 2013/2014. Betriebssysteme / verteilte Systeme rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404 Betriebssysteme I WS 2013/2014 Betriebssysteme / verteilte Systeme rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404 Stand: 16. Januar 2014 Betriebssysteme / verteilte Systeme Betriebssysteme

Mehr

Inhaltsverzeichnis. 2.4 Thread-Systeme. 2.1 Was ist ein Prozess? 2.2 Scheduling. 2.3 Interprozesskommunikation

Inhaltsverzeichnis. 2.4 Thread-Systeme. 2.1 Was ist ein Prozess? 2.2 Scheduling. 2.3 Interprozesskommunikation Inhaltsverzeichnis Systemprogrammierung - Kapitel 2 Prozessverwaltung 1/21 2.1 Was ist ein Prozess? Definition Prozesszustände Prozesskontrollblöcke 2.4 Thread-Systeme Sinn und Zweck Thread-Arten Thread-Management

Mehr

Technische Informatik II

Technische Informatik II Institut für Technische Informatik und Kommunikationsnetze Technische Informatik II Übung 1: Prozesse und Threads Aufgabe 1: Prozesse und Threads a) Wie verhält sich eine Applikation die aus mehreren Prozessen

Mehr

Betriebssysteme. Dipl.-Ing.(FH) Volker Schepper

Betriebssysteme. Dipl.-Ing.(FH) Volker Schepper 1. Der Prozess beginnt im Zustand Erzeugt, nachdem sein Vaterprozess den Systemaufruf fork() (s.u.) abgesetzt hat. In diesem Zustand wird der Prozess-Kontext initialisiert. 2. Ist diese Aufbauphase abgeschlossen,

Mehr

8. Vorlesung Betriebssysteme

8. Vorlesung Betriebssysteme Dr. Christian Baun 8. Vorlesung Betriebssysteme Hochschule Mannheim WS1213 1/69 8. Vorlesung Betriebssysteme Dr. Christian Baun Hochschule Mannheim Fakultät für Informatik wolkenrechnen@gmail.com Dr. Christian

Mehr

6.Vorlesung Betriebssysteme Hochschule Mannheim

6.Vorlesung Betriebssysteme Hochschule Mannheim Christian Baun 6.Vorlesung Betriebssysteme Hochschule Mannheim SS2011 1/40 6.Vorlesung Betriebssysteme Hochschule Mannheim Christian Baun Karlsruher Institut für Technologie Steinbuch Centre for Computing

Mehr

13. Übung mit Musterlösung

13. Übung mit Musterlösung 13. Übung mit Musterlösung 1 Lösung 1 Teil 1.Multiple Choice) Bewertung: Ein Punkt für richtige Antwort, für jede falsche Antwort ein Punktabzug. a) Für die Exponentialverteilung ist die Zeit bis zum nächsten

Mehr

Prozesse. Prozesse. Nebenläufigkeit. Prozess-Scheduling. Echtzeit-Scheduling. Multiproz.-Scheduling. Inhalt Prozesse

Prozesse. Prozesse. Nebenläufigkeit. Prozess-Scheduling. Echtzeit-Scheduling. Multiproz.-Scheduling. Inhalt Prozesse Modul: B-BS Betriebssysteme WS 2012/13 Prozesse Prof. Dr. Rüdiger Brause Adaptive Systemarchitektur Institut für Informatik Fachbereich Informatik und Mathematik (12) Inhalt Prozesse Was ist ein Prozess?

Mehr

Prozesse und Scheduling

Prozesse und Scheduling Betriebssysteme für Wirtschaftsinformatiker SS04 KLAUSUR Vorbereitung mit Lösungen / Blatt 1 Prozesse und Scheduling Aufgabe 1 : Scheduling Gegeben seien die folgenden Prozesse und die Längen des jeweiligen

Mehr

Betriebssysteme Kap F: CPU-Steuerung CPU-Scheduling

Betriebssysteme Kap F: CPU-Steuerung CPU-Scheduling Betriebssysteme Kap F: CPU-Steuerung CPU-Scheduling 1 termini technici Der englische Fachausdruck scheduler wurde eingedeutscht : Der Scheduler Für scheduling ist im Deutschen auch zu verwenden: Ablaufplanung

Mehr

Betriebssystembau (BSB)

Betriebssystembau (BSB) Betriebssystembau (BSB) 6. Übung http://ess.cs.tu-.de/de/teaching/ws2013/bsb/ Olaf Spinczyk olaf.spinczyk@tu-.de http://ess.cs.tu-.de/~os AG Eingebettete System Informatik 12, TU Dortmund Agenda Vorstellung

Mehr

Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008

Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008 Name: Matrikel-Nr: Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008 Bitte schreiben Sie leserlich und antworten Sie kurz und präzise. 1. Zeichnen Sie das Schichten-Modell eines Computersystems und markieren

Mehr

Welche der folgenden Aussagen gelten? a) Im allgemeinen gilt: ein Deadlock tritt auf gdw. der Resource-Allocation Graph einen Zykel

Welche der folgenden Aussagen gelten? a) Im allgemeinen gilt: ein Deadlock tritt auf gdw. der Resource-Allocation Graph einen Zykel Aufgabe 1 (5 Punkte) (Multiple Choice) Beantworten Sie folgende Fragen durch Ankreuzen der richtigen Antwort. Für jede falsche Antwort wird ein Punkt abgezogen (es werden minimal 0 Punkte vergeben). Welche

Mehr

5 CPU Scheduling. FH Regensburg BT/SS04 Betriebssysteme Wirtschaftsinformatik. 5.1 Grundlagen - 54 - 5.1.1 CPU Burst / I/O Burst

5 CPU Scheduling. FH Regensburg BT/SS04 Betriebssysteme Wirtschaftsinformatik. 5.1 Grundlagen - 54 - 5.1.1 CPU Burst / I/O Burst FH Regensburg BT/SS04 5 CPU Scheduling 5.1 Grundlagen 5.1.1 CPU Burst / I/O Burst Beobachtung: Programme rechnen typischerweise etwas, dann tätigen sie Ein/Ausgabe: CPU-Burst: das Programm rechnet eine

Mehr

Rechnernutzung in der Physik. Betriebssysteme

Rechnernutzung in der Physik. Betriebssysteme Rechnernutzung in der Physik Betriebssysteme 1 Betriebssysteme Anwendungsprogramme Betriebssystem Treiber BIOS Direkter Zugriff von Anwenderprogrammen auf Hardware nur in Ausnahmefällen sinnvoll / möglich:

Mehr

Ausarbeitung im Rahmen der PG Autolab zum Thema: OSEK 1 -OS. geschrieben von Oliver Botschkowski

Ausarbeitung im Rahmen der PG Autolab zum Thema: OSEK 1 -OS. geschrieben von Oliver Botschkowski Ausarbeitung im Rahmen der PG Autolab zum Thema: OSEK 1 -OS geschrieben von Oliver Botschkowski 1 Offene Systeme und deren Schnittstelle für die Elektronik im Kraftfahrzeug 1 Oliver Botschkowski - OSEK-OS

Mehr

5) Realzeitscheduling

5) Realzeitscheduling Inhalte Anforderungen Klassifizierungen Verschiedene Verfahren: FIFO, Round Robin, Least Laxity, EDF, fixed/dyn. Prio. Beispiele und Aufgaben Seite 1 Motivation Gegeben: Ein Einprozessorsystem, das Multiprogrammierung

Mehr

Technische Informatik II

Technische Informatik II Institut für Technische Informatik und Kommunikationsnetze Technische Informatik II Übung 3: Input / Output Hinweis: Weitere Aufgaben zu diesem Thema finden sie in den Begleitbüchern zur Vorlesung. Aufgabe

Mehr

Echtzeitfähige Ereignisgetriebene Scheduling-Strategien

Echtzeitfähige Ereignisgetriebene Scheduling-Strategien Friedrich-Alexander-Universität Erlangen-Nürnberg Ausgewählte Kapitel eingebetteter Systeme Echtzeitfähige Ereignisgetriebene Scheduling-Strategien Sven Kerschbaum 1. Einführung Bei einem eingebetteten

Mehr

TIMI: Technische Informatik für Medieninformatiker

TIMI: Technische Informatik für Medieninformatiker TIMI: Technische Informatik für Medieninformatiker Bachelor-Studiengang Digitale Medien Medieninformatik SS 2004 Niels Pollem Arbeitsgruppe Rechnernetze (Prof. Dr.-Ing. Ute Bormann) Scheduling:

Mehr

7.Vorlesung Betriebssysteme Hochschule Mannheim

7.Vorlesung Betriebssysteme Hochschule Mannheim Christian Baun 7.Vorlesung Betriebssysteme Hochschule Mannheim SS2011 1/70 7.Vorlesung Betriebssysteme Hochschule Mannheim Christian Baun Karlsruher Institut für Technologie Steinbuch Centre for Computing

Mehr

Schedulingalgorithmen Rechenzeitverteilung auf Betriebssystemebene. Andi Drebes Fachbereich Informatik Universität Hamburg

Schedulingalgorithmen Rechenzeitverteilung auf Betriebssystemebene. Andi Drebes Fachbereich Informatik Universität Hamburg Schedulingalgorithmen Rechenzeitverteilung auf Betriebssystemebene Andi Drebes Fachbereich Informatik Universität Hamburg Gliederung Notwendigkeit des Schedulings Einführung: Begriff des Multitaskings

Mehr

Scheduling. Gliederung. Was ist Scheduling? Scheduling. Übersicht: 1. Einführung und Übersicht. 2. Prozesse und Threads. 3. Interrupts. 4.

Scheduling. Gliederung. Was ist Scheduling? Scheduling. Übersicht: 1. Einführung und Übersicht. 2. Prozesse und Threads. 3. Interrupts. 4. Gliederung 1. Einführung und Übersicht 2. Prozesse und Threads 3. Interrupts 4. 5. Synchronisation 6. Interprozesskommunikation 7. Speicherverwaltung Cl. Schnörr / HM 1 Gliederung Cl. Schnörr / HM 2 Was

Mehr

RTEMS- Echtzeitbetriebssystem

RTEMS- Echtzeitbetriebssystem RTEMS- Echtzeitbetriebssystem Name: Hussein Hammoud Matrikel- Nr.: 230768 Studiengang: Technische Informatik Fach: Projekt Eingebettete Kommunikation Technische Universität Berlin Sommersemester 2006 RTEMS-

Mehr

183.579, SS2012 Übungsgruppen: Do., 14.6. Mi., 20.6.2012

183.579, SS2012 Übungsgruppen: Do., 14.6. Mi., 20.6.2012 VU Technische Grundlagen der Informatik Übung 8: Systemsoftware und Netzwerke 183.579, SS2012 Übungsgruppen: o., 14.6. Mi., 20.6.2012 ufgabe 1: Virtual Memory Zeichnen Sie ein System das Paging zur Speicherverwaltung

Mehr

Scheduling in Echtzeitbetriebssystemen. Prof. Dr. Margarita Esponda Freie Universität Berlin

Scheduling in Echtzeitbetriebssystemen. Prof. Dr. Margarita Esponda Freie Universität Berlin Scheduling in Echtzeitbetriebssystemen Prof. Dr. Margarita Esponda Freie Universität Berlin Echtzeitsysteme Korrekte Ergebnisse zum richtigen Zeitpunkt Hart Echtzeitsysteme Eine verspätete Antwort ist

Mehr

Einführung in UNIX 1. Das Betriebssystem UNIX ist fähig, mehrere Aufgaben scheinbar gleichzeitig zu erledigen. Dies wird mit Multitasking bezeichnet.

Einführung in UNIX 1. Das Betriebssystem UNIX ist fähig, mehrere Aufgaben scheinbar gleichzeitig zu erledigen. Dies wird mit Multitasking bezeichnet. Einführung in UNIX 1 7 Prozesse Das Betriebssystem UNIX ist fähig, mehrere Aufgaben scheinbar gleichzeitig zu erledigen. Dies wird mit Multitasking bezeichnet. Auf einem UNIX-Rechner können hundert oder

Mehr

Enterprise Computing Einführung in das Betriebssystem z/os. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth WS2012/13

Enterprise Computing Einführung in das Betriebssystem z/os. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth WS2012/13 UNIVERSITÄT LEIPZIG Enterprise Computing Einführung in das Betriebssystem z/os Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth WS2012/13 Verarbeitungsgrundlagen Teil 3 Betriebssystem Überwacher

Mehr

DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Sep 2012. 4) Task-Verwaltung

DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Sep 2012. 4) Task-Verwaltung Inhalte Eigenschaften von Rechenprozessen (Tasks) Taskübergänge (process control block) Multitasking (kooperativ und präemptiv) Scheduler Erzeugen, Starten und Beenden von Tasks Taskzustände (running,

Mehr

Task A Zündung. Task B Einspritzung. Task C Erfassung Pedalwert. J. Schäuffele, Th. Zurawka: Automotive Software Engineering, Vieweg, 2003

Task A Zündung. Task B Einspritzung. Task C Erfassung Pedalwert. J. Schäuffele, Th. Zurawka: Automotive Software Engineering, Vieweg, 2003 Task! evt. parallel zu bearbeitende Ausführungseinheit! Beispiel: Task A Zündung Task B Einspritzung Task C Erfassung Pedalwert Zeit t J. Schäuffele, Th. Zurawka:, Vieweg, 2003 Echtzeitbetriebssysteme

Mehr

Vorl. 6: Single- und Multitasking

Vorl. 6: Single- und Multitasking Universität Bielefeld Technische Fakultät AG Rechnernetze und verteilte Systeme Vorl. 6: Single- und Multitasking Peter B. Ladkin Single Tasking Command Interpreter (ComInt) läuft wartet auf Tastatur-Eingabe

Mehr

Kapitel 2: Betriebssysteme

Kapitel 2: Betriebssysteme LUDWIG- MAXIMILIANS- UNIVERSITY MUNICH DEPARTMENT INSTITUTE FOR INFORMATICS Skript zur Vorlesung: Einführung in die Informatik: Systeme und Anwendungen Sommersemester 2009 Vorlesung: Dr. Peer Kröger Übungen:

Mehr

Prozesse, CPU Umschalten, Dispatching und Scheduling

Prozesse, CPU Umschalten, Dispatching und Scheduling Prozesse, CPU Umschalten, Dispatching und Scheduling Aktive Elemente SS2001 Prof. H. D. Clausen - unisal 1 Prozesse Prozess - Programm in Ausführung sequentielle Programmausführung quasi-simultane Abwicklung

Mehr

Prozesse und Logs Linux-Kurs der Unix-AG

Prozesse und Logs Linux-Kurs der Unix-AG Prozesse und Logs Linux-Kurs der Unix-AG Andreas Teuchert 27./28. Juni 2012 Prozesse unter Linux gestartete Programme laufen unter Linux als Prozesse jeder Prozess hat eine eindeutige Prozess-ID (PID)

Mehr

Projekt für Systemprogrammierung WS 06/07

Projekt für Systemprogrammierung WS 06/07 Dienstag 30.01.2007 Projekt für Systemprogrammierung WS 06/07 Von: Hassan Bellamin E-Mail: h_bellamin@web.de Gliederung: 1. Geschichte und Definition 2. Was ist Virtualisierung? 3. Welche Virtualisierungssoftware

Mehr

Betriebssysteme WS 2012/13 Peter Klingebiel, DVZ. Zusammenfassung Kapitel 4 - Datenträger/Dateiverwaltung

Betriebssysteme WS 2012/13 Peter Klingebiel, DVZ. Zusammenfassung Kapitel 4 - Datenträger/Dateiverwaltung Betriebssysteme WS 2012/13 Peter Klingebiel, DVZ Zusammenfassung Kapitel 4 - Datenträger/Dateiverwaltung Zusammenfassung Kapitel 4 Dateiverwaltung 1 Datei logisch zusammengehörende Daten i.d.r. permanent

Mehr

Vorbereitung zur Prüfung Echtzeitbetriebssysteme

Vorbereitung zur Prüfung Echtzeitbetriebssysteme Vorbereitung zur Prüfung Echtzeitbetriebssysteme Zugelassene Hilfsmittel: Taschenrechner Bitte verwenden Sie keinen roten Farbstift! 1. Echtzeitbetriebssysteme - Allgemein (15 Punkte) 1.1. Warum setzen

Mehr

Betriebssystem? Übersicht. Ziele. Grundlagen. Das ist nur die Oberfläche... Wissen, was man unter einem Betriebssystem versteht

Betriebssystem? Übersicht. Ziele. Grundlagen. Das ist nur die Oberfläche... Wissen, was man unter einem Betriebssystem versteht Betriebssysteme Grundlagen Quellen: InSy Folien zum Thema Unix/Linux Wikipedia Das ist nur die Oberfläche... 1 Ziele 2 Übersicht Wissen, was man unter einem Betriebssystem versteht Was Was ist istein einbetriebssystem?

Mehr

Betriebssysteme. CPU-Scheduling - Fallbeispiele. Sommersemester 2014 Prof. Dr. Peter Mandl. Prof. Dr. Peter Mandl Seite 1.

Betriebssysteme. CPU-Scheduling - Fallbeispiele. Sommersemester 2014 Prof. Dr. Peter Mandl. Prof. Dr. Peter Mandl Seite 1. CPU-Scheduling - Fallbeispiele Sommersemester 2014 Prof. Dr. Peter Mandl Prof. Dr. Peter Mandl Seite 1 Gesamtüberblick 1. Einführung in 2. Betriebssystemarchitekturen und Betriebsarten 3. Interruptverarbeitung

Mehr

Prozesse und Logs Linux-Kurs der Unix-AG

Prozesse und Logs Linux-Kurs der Unix-AG Prozesse und Logs Linux-Kurs der Unix-AG Benjamin Eberle 22. Januar 2015 Prozesse unter Linux gestartete Programme laufen unter Linux als Prozesse jeder Prozess hat eine eindeutige Prozess-ID (PID) jeder

Mehr

2 Echtzeitbetriebssysteme

2 Echtzeitbetriebssysteme 35 2 Echtzeitbetriebssysteme In den letzten Jahren hat sich die Automobilindustrie zu einem der wesentlichen Anwender von Echtzeitbetriebssystemen für eingebettete Systeme entwickelt. Relativ zeitig erkannten

Mehr

A Kompilieren des Kernels... 247. B Lineare Listen in Linux... 251. C Glossar... 257. Interessante WWW-Adressen... 277. Literaturverzeichnis...

A Kompilieren des Kernels... 247. B Lineare Listen in Linux... 251. C Glossar... 257. Interessante WWW-Adressen... 277. Literaturverzeichnis... 1 Einführung................................................ 1 1.1 Was ist ein Betriebssystem?............................... 1 1.1.1 Betriebssystemkern................................ 2 1.1.2 Systemmodule....................................

Mehr

Von Prozessen und Prozessoren (Prozess-Management)

Von Prozessen und Prozessoren (Prozess-Management) Von Prozessen und Prozessoren (Prozess-Management) V1.1 Technische Berufsschule Zürich IT Seite 1 Aus dem Geschichtsbuch: Grossrechner IBM 7094, 1965: Online- und Batchbetrieb IBM-Lochkarte Technische

Mehr

Betriebssysteme Kap A: Grundlagen

Betriebssysteme Kap A: Grundlagen Betriebssysteme Kap A: Grundlagen 1 Betriebssystem Definition DIN 44300 Die Programme eines digitalen Rechensystems, die zusammen mit den Eigenschaften dieser Rechenanlage die Basis der möglichen Betriebsarten

Mehr

Grundlagen der Informatik. Teil VI Betriebssysteme

Grundlagen der Informatik. Teil VI Betriebssysteme Grundlagen der Informatik Teil VI Betriebssysteme Seite 1 Definition nach DIN: Unter Betriebssystem versteht man alle Programme eines digitalen Rechensystems, die zusammen mit den Eigenschaften der Rechenanlage

Mehr

Übung zu Grundlagen der Betriebssysteme. 8. Übung 04.12.2012

Übung zu Grundlagen der Betriebssysteme. 8. Übung 04.12.2012 Übung zu Grundlagen der Betriebssysteme 8. Übung 04.12.2012 Threads Thread (Faden des (Kontrollflusses)): ist ein sequentieller Abarbeitungsablauf (Kontrollfluss) innerhalb eines Prozesses. Umfasst ein

Mehr

Embedded-Linux-Seminare. Linux als Betriebssystem

Embedded-Linux-Seminare. Linux als Betriebssystem Embedded-Linux-Seminare Linux als Betriebssystem http://www.embedded-linux-seminare.de Diplom-Physiker Peter Börner Spandauer Weg 4 37085 Göttingen Tel.: 0551-7703465 Mail: info@embedded-linux-seminare.de

Mehr

5.6 Realzeitarchitektur auf Multicore-Basis

5.6 Realzeitarchitektur auf Multicore-Basis 5.6 Realzeitarchitektur auf Multicore-Basis 63 VxWorks Vertreter eines klassischen Realzeitbetriebssystems mit einer starken Marktdurchdringung ist VxWorks der Firma Wind River. Ursprünglich als Realzeitbetriebssystem

Mehr

Prozesse und Threads. Peter Puschner Institut für Technische Informatik peter@vmars.tuwien.ac.at

Prozesse und Threads. Peter Puschner Institut für Technische Informatik peter@vmars.tuwien.ac.at Prozesse und Threads Peter Puschner Institut für Technische Informatik peter@vmars.tuwien.ac.at 1 Ziel: Gleichzeitiges, kontrolliertes Ausführen von Programmen auf einem Rechner Welche Mechanismen sind

Mehr

B1 Stapelspeicher (stack)

B1 Stapelspeicher (stack) B1 Stapelspeicher (stack) Arbeitsweise des LIFO-Stapelspeichers Im Kapitel "Unterprogramme" wurde schon erwähnt, dass Unterprogramme einen so genannten Stapelspeicher (Kellerspeicher, Stapel, stack) benötigen

Mehr

Prozeß P1 Prozeß P2. Zur Synchronisation stehen den beiden Prozessen binäre Semaphore und die beiden Funktionen

Prozeß P1 Prozeß P2. Zur Synchronisation stehen den beiden Prozessen binäre Semaphore und die beiden Funktionen Seite 8 A UFGABE 11 INTERP ROZEßKOMMUNIKATION Das folgende Petrinetz zeigt zwei verkoppelte Prozesse P1 und P2. Die Transitionen a und b beschreiben Aktionen von P1, die Transitionen c und d Aktionen von

Mehr

Implementierung von Dateisystemen

Implementierung von Dateisystemen Implementierung von Dateisystemen Teil 2 Prof. Dr. Margarita Esponda WS 2011/2012 44 Effizienz und Leistungssteigerung Festplatten sind eine wichtige Komponente in jedem Rechnersystem und gleichzeitig

Mehr

B.4. B.4 Betriebssysteme. 2002 Prof. Dr. Rainer Manthey Informatik II 1

B.4. B.4 Betriebssysteme. 2002 Prof. Dr. Rainer Manthey Informatik II 1 Betriebssysteme Betriebssysteme 2002 Prof. Dr. Rainer Manthey Informatik II 1 Bekannte Betriebssysteme Windows 2000 CMS UNIX MS-DOS OS/2 VM/SP BS 2000 MVS Windows NT Solaris Linux 2002 Prof. Dr. Rainer

Mehr

OSEKtime - Time-Triggered OSEK/OS

OSEKtime - Time-Triggered OSEK/OS OSEKtime - Time-Triggered OSEK/OS Gregor Kaleta gregor.kaleta@udo.edu PG Seminarwochenende 21.-23. Oktober 2007 1 Überblick Einleitung OSEKtime Task-Zustandsmodell, Scheduling-Verfahren Interrupt-Verarbeitung

Mehr

Enterprise Computing Einführung in das Betriebssystem z/os. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth WS2012/13

Enterprise Computing Einführung in das Betriebssystem z/os. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth WS2012/13 UNIVERSITÄT LEIPZIG Enterprise Computing Einführung in das Betriebssystem z/os Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth WS2012/13 Verarbeitungsgrundlagen Teil 2 Virtual Storage el0100 copyright

Mehr

Kapitel III. Prozesse. Prozessverwaltung. Was ist ein Prozess?

Kapitel III. Prozesse. Prozessverwaltung. Was ist ein Prozess? Kapitel III Prozessverwaltung 1 Was ist ein Prozess? Prozesse ein exekutierendes Programm (aktive Einheit) ein Prozess benötigt Ressourcen: CPU-Zeiten, Speicher, Files, I/O Systeme Betriebssystem ist verantwortlich

Mehr

3. Unix Prozesse. Betriebssysteme Harald Kosch Seite 57

3. Unix Prozesse. Betriebssysteme Harald Kosch Seite 57 3. Unix Prozesse Ein Prozeß ist die Umgebung eines laufenden Programms. Ein bißchen Analogie. Wer kocht gerne? Papa möchte mit Hilfe eines Rezeptes eine Torte für seine Tochter backen. Das Rezept ist das

Mehr

3 Task-Leiste Ziele des Kapitels:

3 Task-Leiste Ziele des Kapitels: 3 Task-Leiste Ziele des Kapitels: $ Die Task-Leiste ist ein zentrales Element von Windows 95. Dieses Kapitel zeigt Ihnen, wie Sie die Task-Leiste bei Ihrer Arbeit mit Windows 95 sinnvoll einsetzen können.

Mehr

5 Speicherverwaltung. bs-5.1 1

5 Speicherverwaltung. bs-5.1 1 5 Speicherverwaltung bs-5.1 1 Pufferspeicher (cache) realer Speicher Primärspeicher/Arbeitsspeicher (memory) Sekundärspeicher/Hintergrundspeicher (backing store) (Tertiärspeicher/Archivspeicher) versus

Mehr

Redwood Cronacle und REALTECH theguard! Integration

Redwood Cronacle und REALTECH theguard! Integration Redwood Cronacle und REALTECH theguard! Integration Einleitung Redwood Software und REALTECH haben gemeinsam eine Lösung entwickelt, die die Systemverfügbarkeit von SAP und mysap Systemen signifikant erhöht.

Mehr

POSIX Echtzeit: Kernel 2.6 und Preempt-RT

POSIX Echtzeit: Kernel 2.6 und Preempt-RT POSIX Echtzeit: Kernel 2.6 und Preempt-RT Slide 1 - http://www.pengutronix.de - 21.01.2007 Echtzeit-Systemplanung Wenn das zeitliche Verhalten spezifiziert ist, kann auch spezifiziert werden, welche Applikationsteile

Mehr

BP 2 Prozessorvergabe - Multiprozessoren: Kern-Fäden. besten, wenn der Zusatzaufwand für Kontextumschaltungen gering ist.

BP 2 Prozessorvergabe - Multiprozessoren: Kern-Fäden. besten, wenn der Zusatzaufwand für Kontextumschaltungen gering ist. BP 2 Prozessorvergabe - Multiprozessoren: Kern-Fäden 5.2 Prozessorvergabe für Kern-Fäden Scheduler-Struktur Struktur der Warteschlangen Parallele Bearbeitung von Warteschlangen Strategien Statische oder

Mehr

Prozesse. Stefan Janssen. sjanssen@cebitec.uni-bielefeld.de. Alexander Sczyrba asczyrba@cebitec.uni-bielefeld.de

Prozesse. Stefan Janssen. sjanssen@cebitec.uni-bielefeld.de. Alexander Sczyrba asczyrba@cebitec.uni-bielefeld.de Netzwerk - Programmierung Prozesse Stefan Janssen sjanssen@cebitec.uni-bielefeld.de Alexander Sczyrba asczyrba@cebitec.uni-bielefeld.de Madis Rumming mrumming@cebitec.uni-bielefeld.de Übersicht Prozesse

Mehr

Die Toodledo-Schnittstelle. Klare Ziele Freier Schreibtisch Das Wichtigste zuerst

Die Toodledo-Schnittstelle. Klare Ziele Freier Schreibtisch Das Wichtigste zuerst 6 Die Toodledo-Schnittstelle Klare Ziele Freier Schreibtisch Das Wichtigste zuerst meineziele Herausgeber und Verantwortlicher im Sinne des Presserechts ist die Methode.de GmbH, Springstr. 2, 77704 Oberkirch,

Mehr

CS2101 Nebenläufige und Verteilte Programme Bachelor of Science (Informatik)

CS2101 Nebenläufige und Verteilte Programme Bachelor of Science (Informatik) Prof. Dr. Th. Letschert CS2101 Nebenläufige und Verteilte Programme Bachelor of Science (Informatik) Vorlesung 7 Th Letschert FH Gießen-Friedberg Ressourcen Verwaltung passive Ressourcen aktive Ressourcen

Mehr

A-Plan 12.0. Zeiterfassung 2.0. Ausgabe 1.1. Copyright. Warenzeichenhinweise

A-Plan 12.0. Zeiterfassung 2.0. Ausgabe 1.1. Copyright. Warenzeichenhinweise A-Plan 12.0 Zeiterfassung 2.0 Ausgabe 1.1 Copyright Copyright 1996-2014 braintool software gmbh Kein Teil dieses Handbuches darf ohne ausdrückliche Genehmigung von braintool software gmbh auf mechanischem

Mehr

xcall Technische Dokumentation

xcall Technische Dokumentation xcall Technische Dokumentation zu Version 4.x Autor: Martin Roth Erstelldatum: 14.08.2008 Version: 1.4 Seite 2 / 7 Zweck...3 Schnittstellenarchitektur...3 Outbound-Schnittstellen...3 Outlook...3 TwixTel...3

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

1. Prozesse & Threads (10 Punkte)

1. Prozesse & Threads (10 Punkte) Fachbereich Informatik/Mathematik Seite 1/9 1. Prozesse & Threads (10 Punkte) a) Erklären Sie den Unterschied zwischen Prozessen und Threads. [4 P.] Der wesentliche Unterschied ist, dass Prozesse über

Mehr

Scheduling-Verfahren für Mehrbenutzer-Systeme. Klaus Kusche, Juni 2012

Scheduling-Verfahren für Mehrbenutzer-Systeme. Klaus Kusche, Juni 2012 Scheduling-Verfahren für Mehrbenutzer-Systeme Klaus Kusche, Juni 2012 Inhalt Einleitung & Begriffe Ziele & Voraussetzungen Das Round-Robin-Verfahren...... und seine Probleme Die Scheduler in Windows und

Mehr

Betriebssysteme. 4y Springer. Eine kompakte Einführung mit Linux. Albrecht Achilles. Mit 31 Abbildungen

Betriebssysteme. 4y Springer. Eine kompakte Einführung mit Linux. Albrecht Achilles. Mit 31 Abbildungen Albrecht Achilles 2008 AGI-Information Management Consultants May be used for personal purporses only or by libraries associated to dandelon.com network. Betriebssysteme Eine kompakte Einführung mit Linux

Mehr

Bilder im Internet. Hans Magnus Enzensberger

Bilder im Internet. Hans Magnus Enzensberger Kapitel 4 Alle reden von Kommunikation, aber die wenigsten haben sich etwas mitzuteilen. Hans Magnus Enzensberger Bilder im Internet Nach der etwas umfangreichen vorangehenden Lektion zum Ausklang der

Mehr

Programmierung über den ARCNET-Bus. Programmiersystem. 907 PC 331 Programmier- und Testsoftware. ABB Schaltund Steuerungstechnik

Programmierung über den ARCNET-Bus. Programmiersystem. 907 PC 331 Programmier- und Testsoftware. ABB Schaltund Steuerungstechnik Programmierung über den ARCNET-Bus Programmiersystem 907 PC 331 Programmier- und Testsoftware ABB Schaltund Steuerungstechnik Inhaltsverzeichnis Einbindung ARCNET-Treiber in 907PC331... 3 1 Allgemeine

Mehr

Name: ES2 Klausur Thema: ARM 25.6.07. Name: Punkte: Note:

Name: ES2 Klausur Thema: ARM 25.6.07. Name: Punkte: Note: Name: Punkte: Note: Hinweise für das Lösen der Aufgaben: Zeit: 95 min. Name nicht vergessen! Geben Sie alle Blätter ab. Die Reihenfolge der Aufgaben ist unabhängig vom Schwierigkeitsgrad. Erlaubte Hilfsmittel

Mehr

12 Dokumente verwalten

12 Dokumente verwalten 12 e verwalten 12.1 e organisieren Wir wollen uns nun etwas ausführlicher damit beschäftigen, wo unsere e gespeichert werden. Textverarbeitungsprogramme schlagen beim Speichern einen Ordner vor, in dem

Mehr

Zur Erinnerung: Threads. Threadverwaltung. Threads: Prioritäten. Beispiel Flugbuchungsprogramm. Nichtdeterminismus

Zur Erinnerung: Threads. Threadverwaltung. Threads: Prioritäten. Beispiel Flugbuchungsprogramm. Nichtdeterminismus Zur Erinnerung: Threads Programmierung (fortgeschrittene Konzepte) Threads, Monitore, Semaphore und speisende en Wolf-Ulrich Raffel (uli@wuraffel.de) Möglichkeiten, Threads zu definieren Bildung einer

Mehr

Klassisches Scheduling-Problem 6 Prozesse 3 Prozessoren. Strategie und Mechanismus

Klassisches Scheduling-Problem 6 Prozesse 3 Prozessoren. Strategie und Mechanismus Betriebssysteme Sommersemester 0. Einführung Betriebssysteme. Kapitel Scheduling Prof. Matthias Werner Professur Betriebssysteme Scheduling (etwa: Ablaufplanung): Zeitliche Zuordnung von Aktivitäten zu

Mehr

5. Threads, Serverprozesse und Benachrichtigungen

5. Threads, Serverprozesse und Benachrichtigungen 5. Threads, Serverprozesse und Benachrichtigungen Threads allgemein Threads in Android: Handler und Messages Services: Local, Remote, Binding Benachrichtigungen Entwicklung mobiler Anwendungen Europäische

Mehr

PARAGON Encrypted Disk

PARAGON Encrypted Disk PARAGON Encrypted Disk Anwenderhandbuch Paragon Technologie, Systemprogrammierung GmbH Copyright Paragon Technologie GmbH Herausgegeben von Paragon Technologie GmbH, Systemprogrammierung Pearl-Str. 1 D-79426

Mehr

Im Original veränderbare Word-Dateien

Im Original veränderbare Word-Dateien Software Im Original veränderbare Word-Dateien Prinzipien der Datenverarbeitung Als Software bezeichnet man alle Programme, die in einer Computeranlage verwendet werden. Dabei unterscheiden wir zwischen

Mehr

1.6 Anwendung/Prozesse, Umleitung und Verkettung

1.6 Anwendung/Prozesse, Umleitung und Verkettung 1.6 Anwendung/e, Umleitung und Verkettung 1.6.1 e Ein (englisch task) ist ein im Lauf befindliches Programm. Auf einem Linux-System erhält man mit den Befehlen ps (process list), top (table of processes)

Mehr

6.1 Einführung. Kapitel 6 Scheduling. Klassisches Scheduling-Problem. Anwendungs-Beispiele von Scheduling. Scheduling (zu deutsch etwa

6.1 Einführung. Kapitel 6 Scheduling. Klassisches Scheduling-Problem. Anwendungs-Beispiele von Scheduling. Scheduling (zu deutsch etwa 6.1 Einführung Kapitel 6 Scheduling Scheduling (zu deutsch etwa Ablaufplanung ) bedeutet i.a. die Zuordnung von Aktivitäten zu Instanzen, welche diese Aktivitäten durchführen können, in Raum und Zeit.

Mehr

20 Eingebettete Software

20 Eingebettete Software 20 Eingebettete Software 20.0 Einführung Lernziele Echtzeitsysteme Eingebettete Systeme 20.1 Entwurf eingebetteter Systeme Modellierung von Echtzeitsystemen Programmierung von Echtzeitsystemen 20.2 Architekturmuster

Mehr

Dipl.-Inf. J. Richling Wintersemester 2003/2004. Weiche Echtzeit

Dipl.-Inf. J. Richling Wintersemester 2003/2004. Weiche Echtzeit Dipl.-Inf. J. Richling Wintersemester 2003/2004 Weiche Echtzeit Wiederholung - Resultat/Wert-Funktion "harte" Echtzeit Wert Zeit Wert Zeit Wert Deadline Zeit "weiche" Echtzeit Wert Deadline Zeit Deadline

Mehr

Der SUN-Pool. 64 Arbeitsplätze, reine Terminals

Der SUN-Pool. 64 Arbeitsplätze, reine Terminals Der SUN-Pool 64 Arbeitsplätze, reine Terminals 4 SUN-Server (SUN-Fire oder Enterprise) {alexander,delenn,ivanova,winter}.babylon.cs.uni-potsdam.de, vollkommen symmetrisch installiert; verwalten dasselbe

Mehr

Bitte verwenden Sie nur dokumentenechtes Schreibmaterial!

Bitte verwenden Sie nur dokumentenechtes Schreibmaterial! VO 182.711 Prüfung Betriebssysteme 8. November 2013 KNr. MNr. Zuname, Vorname Ges.)(100) 1.)(35) 2.)(20) 3.)(45) Zusatzblätter: Bitte verwenden Sie nur dokumentenechtes Schreibmaterial! 1 Synchronisation

Mehr

4 Planung von Anwendungsund

4 Planung von Anwendungsund Einführung 4 Planung von Anwendungsund Datenbereitstellung Prüfungsanforderungen von Microsoft: Planning Application and Data Provisioning o Provision applications o Provision data Lernziele: Anwendungen

Mehr

Einführung in PHP. (mit Aufgaben)

Einführung in PHP. (mit Aufgaben) Einführung in PHP (mit Aufgaben) Dynamische Inhalte mit PHP? 2 Aus der Wikipedia (verkürzt): PHP wird auf etwa 244 Millionen Websites eingesetzt (Stand: Januar 2013) und wird auf etwa 80 % aller Websites

Mehr

CompuLok Zentrale. Software Interface. Digitalzentrale für DCC und Motorola Format

CompuLok Zentrale. Software Interface. Digitalzentrale für DCC und Motorola Format CompuLok Zentrale Software Interface Digitalzentrale für DCC und Motorola Format Inhalt CompuLok Software Interface... 3 Das Software Interface... 3 Installation... 3 Treiber installieren.... 3 Hinweis

Mehr