Lernzusammenfassung Unix-API und Werkzeuge. Stefan Bethge 12. September 2011

Transkript

1 Lernzusammenfassung Unix-API und Werkzeuge Stefan Bethge 12. September Prozesse UNIX-Prozesse lassen sich als eine Menge von Befehlen und Daten einschließlich der aktuellen Werte der zugehörigen Prozessorregister auffassen. Ein Prozess ist damit abstrakt ein Tupel, das einen entsprechenden CPU-Zustand vollständig charakterisiert. 1.1 UNIX-Prozessmodell Unter UNIX ist ein Prozess Code, der ausgeführt wird und so Systemressourcen wie CPU- Zeit und Arbeitsspeicher belegt. Ist dieser Code bzw. das Programm nicht geladen und wird nicht ausgeführt, so ist es kein Prozess. Diese Unterscheidung ist nötig, da ein Prozess immer eine Instanz eines ausführbaren Programms ist, so dass mehrere Instanzen gleichzeitig existieren können, welche über ihre Prozess-ID (PID) identifiziert und angesprochen werden können. Das Programm existiert (idealerweise) nur einmal auf der Festplatte. PIDs sind meist eine 16-bit-Zahl, die von einem Counter ab Systemstart hochgezählt werden. Der init- Prozess hat damit meist die PID 0. Weiterhin hat jeder Prozess (bis auf Init) noch einen Elternprozess, dessen PID in der PPID gespeichert ist. Ein Prozess befindet sich in einer Prozessgruppe (beim Erstellen automatisch in der Gruppe des Elternprozesses). Prozesse können als aktive oder passive Elemente betrachtet werden. Aktiv Prozesse... werden geboren, leben und sterben sind in ihrer Zahl variabel können Ressourcen belegen und freigeben können einander beeinflussen können zusammenarbeiten können in Konflikt geraten (sich blockieren)

2 können Ressourcen teilen können voneinander abhängig sein können parallel arbeiten, gleichberechtigt sein können hierarchisch voneinander abhängig sein Passiv Prozesse werden von aktiven Elementen Prozessor und Peripherie beeinflusst; der Prozess erscheint als Datenstruktur. Die zu einem Prozess gehörenden Datenstrukturen sind unter UNIX: Codesegment Anfangszustand im File, sonst im Speicher oder geswappt Datensegment Anfangszustand im File, sonst im Speicher oder geswappt Stacksegment im Speicher oder geswappt Eintrag in der proc-liste immer im Speicher, Headerfile: sys/proc.h user-struktur (u-struktur) im Speicher oder geswappt, Headerfile: sys/user.h Prozesse können über Signale veranlasst werden, Aktionen auszuführen, z. B. sich selbst zu beenden, Konfigurationsdateien neu einzulesen oder aktuelle Abläufe zu unterbrechen, abhängig von den Signalbehandlungsroutinen im Programm. Signale können z. B. mit kill geschickt werden. Jedem Prozess ist ein nice-wert zugeordnet, der eine Nettigkeit von 20 bis +20 angibt; je höher der Wert desto mehr Ressourcen werden für anderer Prozesse übrig gelassen. Der Standardwert ist der ausgewogene Wert 0, der den meisten Prozessen zugeordnet wird proc-struktur (sys/proc.h) p_pid pp_pid p_pgrp p_uid p_gid p_suid p_sgid Prozessnummer Elternprozessnummer Prozessgruppenidentifier Useridentifier Gruppenidentifier effektiver Useridentifier effektiver Gruppenidentifier (+ viele weitere Flags, die Zustände, Speichermanagementflags,... enthalten) Prozesse haben Zugriffsrechte, welche von dem aufrufenden Benutzer und den Flags für die Ausführbare Datei (setuid, sticky-bit) abhängig sind. Die effektive uid/guid ist dabei nicht unbedingt gleich der uid, da z.b. ein von root gestarteter Prozess Privilegien abgeben kann um sicherer gegen Fehlverhalten oder Einbrüche zu sein. Die wichtigsten Zustände: 2

3 dead ready running sleep trace wait uninterruptible sleep zombie Der Prozess wurde beendet, er belegt jedoch noch Speicherplatz. Der Prozess wartet auf Zuteilung der CPU (Zeitscheibe). Gibt es den Ready-Zustand, so befinden sich höchstens so viele Prozesse im Zustand running, wie CPUs vorhanden sind. Entweder genau der Prozess, der gerade bearbeitet wird, oder alle Prozesse, die momentan Rechenarbeit verrichten können. Der Prozess wurde auf eigenen Wunsch zurückgestellt. Er kann Signale entgegennehmen, wie z. B. Timer, oder Ergebnisse von Kindprozessen. Der Prozess wurde von außen angehalten, üblicherweise durch einen Debugger. Der Prozess wartet auf ein Ereignis, üblicherweise eine Benutzereingabe. Der Prozess wartet auf ein Ereignis, üblicherweise Hardware. Tritt dieses Ereignis ein, ohne dass der anfragende Prozess es entgegennimmt, so kann das System instabil werden. Der Prozess ist beendet, aber noch nicht aus der Prozessliste entfernt, da er noch auf einen anderen Prozess wartet (Keine Rechenzeit mehr nötig aber belegt noch Speicher) user-struktur (sys/user.h) Ausführungsstatus, Deskriptortabellen usw Inter-Process-Communication Zwischen Prozessen in einem System mit jeweils eigenem Speicherbereich (auch auf derselben Maschine) ist es unter Umständen nötig, zu kommunizieren. Dafür sind gemeinsame Ressourcen nötig, die allerdings nicht von mehreren Threads oder Prozessen gleichzeitig geschrieben werden dürfen, um nicht in undefinierte Zustände zu gelangen (konsistente Datenstrukturen). Locks Sperren aller anderen Operationen, solange aktueller Thread die Resource benutzt (binärer Semaphor). Vor allem mit atomaren Hardwarecalls( test-and-set, fetch-and-add ) umsetzbar, während dessen keine Unterbrechung passieren kann. Semaphore Datenstruktur aus mit Zähler für Anzahl gleichzeitiger Verwendungen der Ressource und Operationen Reservieren/Probieren(Zä. +1) und Freigeben (Zä. -1). Warteschlange für überschüssige Anfragen. Mutexe (Mutual Exclusive) oft identisch mit binärem Semaphor, allgemein ein Verfahren, den gegenseitigen Ausschluss sicherzustellen 3

4 1.1.4 Statuswechsel Modellweise betrachtet, wechselt ein Prozess zwischen den Zuständen running, blocked und ready. Running bedeutet, dass der Prozess normal abläuft und vom Scheduler Zeitbereiche zugeteilt bekommt, wobei zwischen running und ready gewechselt wird (immer nur ein Prozess pro CPU auf running). Sobald auf externe Ereignisse gewartet wird (read, write, wait), übergibt der Scheduler an einen anderen Prozess und der Status ändert sich zu blocked. Dieser kann nur verlassen werden, wenn das Ereignis eintrifft, was einen Wechsel zu ready bedeutet. In der Realität ist dieser Prozess weitaus komplexer da Prozesse ausgelagert werden können, Zombies möglich sind und Interrupts auftreten. Außerdem existieren user mode und kernel mode bei dem das Killen nicht möglich ist Scheduling Problem: Wer darf in Multiprozessumgebungen wann den Prozessor wie lange benutzen? verschiedene Schedulingverfahren, u. A.: Round Robin Scheduling Prozessschlange, gleiche Zeitquanten, jeder Prozess kommt der Reihen nach ran und wird danach wieder hinten angestellt. Problem: Prozesswechseln benötigt Zeit, z.b. 2 ms, wie groß Zeitquanten wählen? so dass Overhead prozentual klein bleibt, z.b ms) Mehrfache Schlangen Neue Prozesse werden ans Ende der höchsten Queue angehangen und rutschen dort nach vorne. Wenn das Zeitquantum eines Prozesses abgelaufen ist, bevor dieser von selbst die Kontrolle abgegeben hat, wird dieser in der nächst tieferen Queue wieder eingereiht, bis herunter zum Basislevel auf welchem dann wieder Round Robin durchgeführt wird. Von dort kann ein Prozess entkommen, wenn er auf I/O wartet (blocking). Das resultiert darin, dass kurze Jobs bevorteilt werden und im Endeffekt mehr Zeit für rechenintensive Prozesse übrigbleibt. Problem: abwechselnd interaktive und CPU-intensive Prozesse werden mit der Zeit immer reaktionsärmer Shortest Job First Ermittlung der Laufzeit aller Prozesse, die kürzesten werden zuerst ausgeführt, wodurch eine minimale durchschnittliche Wartezeiten erreicht werden (langsame Prozesse müssen meist auch weniger reaktiv sein). Problem: Woher weiß man vorher, wie lange ein Prozess braucht? Möglich ist Benutzerangabe oder Messen und Schätzen. Mittlere Wartezeit: ta + (ta + TB) + (ta+tb+tc) / 3 Zeitüberwachte Steuerung (a priori scheduling) Ziel: gleichverteilte CPU-Zeit über die Zeit der Sitzung, dafür ist nötig: Login-Zeit, Anzahl der eingeloggten Nutzer, bisher verbrauchte Zeit Die Priorität berechnet sich dann über: verbrauchte Zeit Zeit seit Login Anzahl der Nutzer 4

5 Zweistufiges Scheduling Problem: nicht alle Prozesse passen gleichzeitig in den Hauptspeicher, Swapping durch den Scheduler wird nötig. Bei z. B. round-robin würden ständig ausgelagerte Prozesse in den Speicher geladen und andere ausgelagert wobei viel Zeit verschwendet werden würde (manche können länger ausgelagert bleiben als andere). Daher wird in zwei Scheduling-Stufen unterschieden, von denen die Erste für kleine Quanten eine der bisherigen Schedulerstrategien verwendet. Die Zweite verwaltet Prozesse mit großen Quanten und bestimmt, ob ein Prozess geswappt wird, abhängig von Verweildauer und verbrauchter CPU-Zeit (also Prozesse, die bereits länger laufen) Systemrufe zur Prozesssteuerung include <sys/types.h> include <unistd.h> pid_t getpid(void) pid_t getppid(void) uid_t getuid(void) uid_t geteuid(void) Ermitteln einiger Werte zur Prozessidentifikation des aktuellen Prozesses Wertebereich PID (Linux 2.6): pid: (default) bis maximal 2 22 = gid, uid: pid_t fork(void) Erzeugen eines neuen Prozesses, Kind ist vollständige Kopie des Alten, der nun der Elternprozess des Kindes wird. Der Rückkehrwert von fork im Kindprozess ist 0, der Elternprozess bekommt PID des Kindprozesses. Der Kindprozess bekommt eigenes Stack-Segment und Daten-Segment (Kopie) und Locks und prozessspezifische Zeitangaben werden zurückgesetzt. Alles Andere ist gleich - u. A. Filedeskriptoren und offene Files, Signalhandler, Nice-Werte, Shared Memory, Limits und Buffer (z.b. um in Dateien zu schreiben). Unter Unix werden alle Prozesse mit fork() erzeugt (Bzw. in neueren linux-versionen wird für alle Prozesse clone() verwendet, auch fork() benutzt den clone()-syscall) pid_t fork1(void) (Solaris >=10) wie fork, aber zusätzlich wird aktueller thread gedoppelt. pid_t vfork(void) (BSD) wie fork, aber ohne Kopie des Daten- und Stacksegmentes. Der Parentprozess wird angehalten und wartet auf den Kindprozess. Es darf nichts anderes gemacht werden, als execve oder exit aufzurufen, anderes Verhalten ist undefiniert. Da die Performancevorteile von vfork mit der Einführung von copy-on-write beim herkömmlichen fork verschwunden sind, ist es meist mehr nicht ratsam, vfork zu benutzen. 5

6 Prozessbeendigung geschieht über exit() bzw. ein return() in der main()-routine des Hauptprogramms oder abnormal über abort() oder Signalbehandlung. pid_t wait(int *statloc) pid_t waitpid(pid_t pid, int *statloc) Elternprozesse müssen auf die Beendigung eines Kindes warten, Rückgabecode ist PID des Kindprozesses. Prozesse die beendet sind aber auf die (noch) nicht gewartet wurde heißen Zombies. exec() (Kind-)prozesse können neues Programm inerhalb eines Prozesses starten. Dabei wird das aktuelle Code- und Datensegment überlagert, das Stacksegment wird zurückgesetzt. Verschiedene Prozess-IDs sind änderbar: UID, SUID, GID, EUID, EGID, PGID, SID setuid(uid_t uid), setsuid(...), setgid(...),... 2 Threads Threads sind leichtgewichtige Prozesse bzw. ein Thread ist einer von mehreren Ausführungssträngen eines Prozesses. Es kann mehrere Threads in einem Prozess geben; Threads existieren immer in einem Prozess. Neben Kernelthreads existieren auch User Threads, die dann ausschließlich der Obhut des Prozesses selbst unterliegen. Ein Thread teilt sich mit den anderen Threads im Prozess das Codesegment, das Datensegment und die verwendeten Dateideskriptoren. Da damit nur das Stacksegment und Register verschieden sind, kann es Konflikte beim Zugriff auf die gleichen Daten geben, die durch Synchronisationsmechanismen behandelt werden müssen (Semaphores, Mutexe,...). Unter linux werden Threads mit clone() erzeugt, das intern auch von fork() verwendet wird und somit die Threads 1:1 auf Prozesse abbildet. Threads sind damit von Prozessen nur im Detail verschieden, bauen aber auf eine besondere Behandlung im Kernel auf, so dass sie z. B. nicht als Prozesse in /proc erscheinen und threads eine TID bekommen. Normale Prozesse besitzen einen Thread mit gleich PID. Welche Ressourcen mit dem Erstellenden Prozess geteilt werden kann aber durch Optionen auch angepasst werden. Plattformübergreifende Threadbehandlung kann mit POSIX-Threads (<pthread.h>) realisiert werden, da z. B. Solaris nicht mit clone() und der CLONE_THREAD-Option klarkommen würde. Dieses API ist auf verschiedenen Systemen spezifisch implementiert. Probleme die bei der Arbeit mit Threads auftreten können: Programmkomplexität: Threads erzeugen einen Overhead. Wenn Threads nicht unbedingt nötig sind, sollte man darauf verzichten. Synchronisationsprobleme Deadlocks: Gegenseitiges Warten (evtl. über Dritte Konstrukte) führen zu Stillstand. 6

7 Eintrittsinvariante (Biliotheks-)Routinen und Threadcode selbst sind notwendig um die Threadunterbrechung an jedem Punkt zu erlauben. wichtige Operationen der libpthread: pthread_create Starten eines neuen Threads pthread_exit Beenden eines Threads (nach getaner Arbeit) pthread_cancel Abbrechen eines Threads von Außen pthread_join Warten auf das Ende eines Threads (vgl. wait()) pthread_detach Freigeben eines Threads, Ressourcen werden bei Beendigung des Threads sofort Freigegeben ohne das join nötig ist. 3 Versionskontrollsysteme Ziele: Kontrollierter Zugriff Zugriff auf vorherige Versionen Dokumentation der Änderungen Parallelen Zugriff organisieren Entwicklung der wichtigsten Systeme: SCCS RCS CVS SVN... Grundlegend exisitiert ein Repository, das alle Quellen und Diffs enthält. Benutzer arbeiten mit einer lokalen Kopie ( = Sandbox) welche über das System mit dem Repository synchronisiert wird. Dabei bestehen unterschiede je nachdem ob es sich um ein zentrales oder verteiltes System handelt. Allgemein sind verschiedene Operationen nötig, wie init, import, checkout, commit, update Diese sind je nach System etwas anders benannt oder mit anderer Semantik belegt. 3.1 CVS CVS (etwa seit 1989) ist im Gegensatz zu seinen Vorgängern direkt netzwerkfähig (CVS- Server oder ssh) und benutzt ein zentrales Repository in dem alle Änderungen gespeichert werden. Aktionen wie commit oder log benötigen daher (Netzwerk-)Zugriff auf das Repository. CVS führt standardmäßig kein locking beim checkout durch, so dass Konflikte manuell behoben werden müssen, sofern CVS das nicht automatisch schafft. 7

8 cvs watch/edit/unedit erlauben aber (schwache) locks die den Benutzer benachrichtigen, wenn eine Datei zum editieren geöffnet wurde. CVS besitzt branches die mit cvs tag erzeugt werden. 3.2 Subversion 2.Tools: svn und svnadmin svnadmin Zum Erstellen(create) und Verwalten(dump,load) eines Repositories (nur lokal) svn Zum Erstellen(checkout) und Verwalten(update,commit,...) einer lokalen Sandbox, die mit dem Repository, auch remote, abgeglichen wird. Weitere Kommandos sind: add status copy import log merge revert switch update SVN kann remote über svnserve, apache2(http, webdav) oder ssh zur Verfügung stehen. 3.3 Git Git besitzt kein Repository im eigentlichen Sinne, alle Kopien sind gleichwertig und enthalten die gesamte Geschichte, lediglich durch die Organisation sind ßentrale"Repositories festgelegt, zu denen von Benutzern synchronisiert wird. Jeder Commit ist kryptografisch von den vorherigen abhängig (commit ID), wodurch nachträgliche Änderungen der Historie unmöglich sind. Gute Unterstützung für nicht lineare Entwicklung, schnelles branching und merging. 4 Make Make ist ein Werkzeug, das vor Allem das Erstellen von Projekten (mit einem Compiler) erleichtert. Dabei werden die Abhängigkeitsregeln der meist vielzahligen Objekte in einem Makefile formal festgehalten, um diese korrekt zu erstellen und zusammenzufassen. 8

9 Zudem wird durch die Beachtung von Zeitstempeln keine unnötige Arbeit mehrfach verrichtet. Der Aufruf erfolgt über make <target>, wobei ein Target im Makefile über Regeln definiert wird, die wie folgt aussehen: <Targetname>: { <Quellobjekt> } [; <Kommando>] Wobei Quellobjekte Dateinamen (vor allem *.c) sein können oder Namen anderer Targets. Quellobjekte sind die Abhängigkeiten einer Regel und müssen zuvor erfüllt, also in der Regel zuvor kompiliert sein. Weitere Kommandozeilen sind möglich und müssen zwingend mit einem Tabulator eingerückt werden. Variablen heißen Makros, MAKRO = <String>. Der Zugriff erfolgt mit $(<Makroname>). Umgebungsvariablen der Shell werden ebenfalls wie Makros behandelt und es existieren einige vordefinierte Interne Makros: $@ - Name des Objektes das erzeugt werden soll (Name der aktuellen Regel/Target) $< - Name der ersten Abhängigkeit/transformierbaren Objektes $? - Namen aller Abhängigkeiten, die neuer als das Target sind $ - Namen aller Abhängigkeiten 9