2.2 Adressraumverwaltung Code und Daten Einfachster Fall: 0 length-1

2.2 Adressraumverwaltung Code und Daten Einfachster Fall: 0 length-1 CodeDaten Besser: getrennte Segmente, schreibgeschützer Code 0 cl-1 0 dl-1

Unix: 3 Segmente (oder mehr) mit variable Länge Code Keller (stack) statische Daten Halde Längenänderung durch brk Überlauf (und durch exec, Programm laden,  2.3) brk(addr), sbrk(incr) lässt das Datensegment bis Adresse addr-1 reichen bzw. verlängert das Datensegment um incr Fehler ENOMEM beim Überschreiten der maximalen Segmentgröße

Achtung: brk wird typischerweise von der Haldenverwaltung einer höheren Programmiersprache eingesetzt, nicht vom Programmierer Beispiel C: malloc impliziert ein sbrk, wenn die Halde überläuft

Weitere Operationen bei Betriebssystemen  mit reichhaltiger strukturierten Adressräumen  mit überlappenden Adressräumen z.B. mmap, munmap,...

2.3 Ein/Ausgabesystem ist meist geräteunabhängig realisiert: Prozess verfügt über Ein/Ausgabekanäle (channels, ports, open files,...) hinter denen sich Datenquellen/senken verbergen (Geräte, Dateien, Prozesse,...). Kanal = gepufferter Strom von Bytes Kanalnummer (in Unix „file descriptor“) 0, 1, 2,... identifiziert Kanal Kanal kann auch über mehrere Nummern identifiziert werden.

Standardkanäle in Unix, vom Befehlsinterpretierer (Shell) so eingerichtet: 0Standard-Eingabekanal (standard input, stdin), häufig verbunden mit der Tastatur 1Standard-Ausgabekanal (standard output, stdout) häufig verbunden mit dem Bildschirm 2 Standard-Fehlerkanal (standard error, stderr) häufig verbunden mit dem Bildschirm ! Ein Kanal kann auch gleichzeitig Ein- und Ausgabekanal sein !

Prozess P Prozess Q Scanner 4 Dateisystem

ProzesseKanalnummernKanälez.B. Dateien 1 3 P 5 2 Q 3 Kanalnummern, Kanäle und Datenquellen/senken: pos s.u.

Ein/Ausgabe-Operationen: read(channel,buffer,nbytes) liest – sobald Bytes im Kanal vorhanden – maximal nbytes Bytes von channel nach buffer und liefert die Anzahl der gelesenen Bytes (weniger gelesen wird z.B. bei Dateiende oder Zeilenende [beim Lesen von der Tastatur]) Fehler:  ungültige Kanalnummer  Kanal ist nur Ausgabekanal  nicht behebbarer Lesefehler

write(channel,buffer,nbytes) schreibt – sobald Platz im Kanal vorhanden – maximal nbytes Bytes von buffer nach channel und liefert die Anzahl der geschriebenen Bytes (i.d.R. = nbytes ) Fehler:  ungültige Kanalnummer  Kanal ist nur Eingabekanal  nicht behebbarer Schreibfehler

close(channel) macht die Kanalnummer channel ungültig; falls dies die letzte gültige Nummer für den Kanal war, wird dieser gelöscht. Fehler EBADF falls ungültige Kanalnummer channel dup(channel) liefert neue – zuvor ungültige – Kanalnummer, die jetzt den gleichen Kanal wie channel identifiziert; gewählt wird die kleinste der ungültigen Nummern. Fehler EBADF falls ungültige Kanalnummer channel

dup2(old,new) vereinbart, dass die Kanalnummer new den gleichen Kanal wie old identifiziert; falls die Nummer new schon vorher einen Kanal bezeichnete und falls sie die letzte Nummer für diesen Kanal war, wird der Kanal gelöscht. Fehler EBADF falls ungültige Kanalnummer old

2.4 Interprozesskommunikation (inter-process communication, IPC) erfolgt typischerweise über Ein/Ausgabekanäle, in Unix u.a. über Pipes („Rohre“): Pipe =Puffer für Bytes (endliche Kapazität PIPE_MAX ) (Variante: Puffer-Paar für bidirektionale Kommunikation) Bytes senden mit write Bytes empfangen mit read

Operation pipe(channel) mit int channel[2] erzeugt Pipe und richtet einen Eingabekanal für das Empfangen und einen Ausgabekanal für das Senden ein; channel[0] wird mit der Nummer des Eingabekanals belegt, channel[1] wird mit der Nummer des Ausgabekanals belegt, Fehler EMFILE beim Überschreiten der maximalen Anzahl von Kanälen u.a.

Fehler beim Benutzen von Pipes: Kopf des Puffers ist keinem Kanal mehr zugeordnet  write generiert Unterbrechung SIGPIPE Ende des Puffers ist keinem Kanal mehr zugeordnet und der Puffer ist leer  read erkennt „Dateiende“ (end-of-file) Zyklisch über Pipes verbundene Prozesse und alle Puffer voll und alle Prozesse hängen in write  Verklemmung, nicht gemeldet!

Typische Benutzung von Pipes: pipe(channel); if(fork()!=0) { /* parent process */... write(channel[1],...)... else { /* child process */... read(channel[0],...)... zuzüglich Fehlerbehandlung Beachte: Kindprozess erbt Kanäle des Erzeugerprozesses

2.5 Dateiverwaltung Dateien werden durch Namen identifiziert: einfacher Dateiname, z.B. sort Pfadname (pathname), z.B. /usr/bin/sort Verschiedene Dateiarten (Untertypen von „Datei“ in OO BS):  Daten  Programm  Verzeichnis, Ordner (directory, folder)  Pseudodatei (special file): E/A-Gerät  u.a.

Prozess besitzt aktuelles Verzeichnis (working directory): alle Pfadnamen, die nicht mit / beginnen, werden automatisch vorne um den Namen des aktuellen Verzeichnisses erweitert Operation chdir(name) mit char *name setzt das aktuelle Verzeichnis auf name Fehler ENOENT wenn das Verzeichnis name nicht existiert u.a.

Erzeugen und Öffnen von Dateien: open(name,flags) erzeugt und/oder öffnet die Datei name gemäß den Angaben in flags und liefert die Nummer eines Kanals, über den auf die Datei zugegriffen werden kann. Die flags sind u.a. O_CREAT erzeugen, falls nicht vorhanden O_RDONLY nur Lesezugriff O_WRONLY nur Schreibzugriff O_RDWR Lese- und Schreibzugriff Fehler EACCES wenn gewünschter Zugriff nicht erlaubt u.a.

Direktzugriff möglich mit lseek(channel,offset,whence) setzt die Zugriffsposition in der über channel erreichbaren Datei bei whence = 0 auf offset, bei whence = 1 auf aktuelle Position + offset, bei whence = 2 auf Dateilänge + offset. Fehler ESPIPE wenn channel sich auf eine Pipe bezieht u.a.

Laden von Programmen mit Varianten von exec, z.B. execv(program,argv) mit char *argv[] ersetzt das laufende Programm durch das in der Datei program vorgefundene Programm, springt an den Anfang von main und übergibt dabei die Zeichenketten im Feld argv als Parameter für main. Routinen für die Unterbrechungsbehandlung gehen verloren ! Fehler EACCES wenn Datei nicht als Programm ladbar u.a.

+ weitere Operationen für Abfragen/Setzen von Dateieigenschaften Maßnahmen zum Zugriffsschutz usw.

2.6 C-Bibliotheken Dringende Leseempfehlung zu Unix: man –s1 intro Benutzerschnittstelle (Shell) man –s2 intro Systemschnittstelle man –s3 intro Weitere Bibliotheken /usr/include Help-Dateien.h /usr/lib Bibliotheken

2.6.1 Weitere Bibliotheken man –s3 intro liefert eine Übersicht über die in Abschnitt 3 der Dokumentation beschriebenen Bibliotheken für C mit einer Vielzahl von Prozeduren („C library functions“) jenseits der in Abschnitt 2 beschriebenen Systemaufrufe, z.B.

malloc (2.2  )2.2 printf formatierte Ausgabe auf stdout fopen gepufferte Datei-Ein/Ausgabe fread... sqrt,...mathematische Funktionen etc.

2.6.2 Nichtsequentielle Benutzung Falls Threading unterstützt wird – Achtung bei nebenläufiger Benutzung von Bibliotheken! Nicht jede Prozedur ist thread-safe! Gegebenenfalls Sperrsynchronisation vornehmen! Z.B. in Solaris ist jeder Bibliotheksprozedur zugeordnet ein MT-Level (multi-threading level): Unsafe, Safe, MT-Safe, Async-Signal-Safe

Unsafe:unsicher Beispiel: rand (3) Safe:sicher Beispiel: malloc (3) MT-Safe:sicher, mit interner Nebenläufigkeit Beispiel: sqrt (3) Async-Signal-Safe:wie MT-Safe, sogar beim Auftreten von (Software-)Unterbrechungen (durch Unterbrechungsunterdrückung während kritischer Abschnitte) Beispiel: write (2) + Varianten