2.2 Adressraumverwaltung

Code und Daten

Einfachster Fall:

0 length-1

2.2 Adressraumverwaltung

Code und Daten

Einfachster Fall:

0 length-1

Code Daten

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 DatenHalde

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 reichenbzw. verlängert das Datensegment um incr

Fehler ENOMEM beim Überschreiten der maximalenSegmentgröße

Achtung:

brk wird typischerweise von der Haldenverwaltung einerhö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:

0 Standard-Eingabekanal (standard input, stdin),häufig verbunden mit der Tastatur

1 Standard-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

120

3

5

Scanner

4

Dateisystem

Prozesse Kanalnummern Kanäle z.B. Dateien

1

3P

5

2Q

3

Kanalnummern, Kanäle und Datenquellen/senken:

pos

pos

pos

s.u.

Ein/Ausgabe-Operationen:

read(channel,buffer,nbytes)liest – sobald Bytes im Kanal vorhanden – maximal nbytes Bytes von channel nach bufferund liefert die Anzahl der gelesenen Bytes(weniger gelesen wird z.B. bei Dateiende oderZeilenende [beim Lesen von der Tastatur])

Fehler: ungültige KanalnummerKanal ist nur Ausgabekanalnicht 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 KanalnummerKanal ist nur Eingabekanalnicht 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, diejetzt 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 newden 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 Eingabekanalfür das Empfangen und einen Ausgabekanalfü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 maximalenAnzahl von Kanälenu.a.

Fehler beim Benutzen von Pipes:

Kopf des Puffers ist keinem Kanal mehr zugeordnetwrite generiert Unterbrechung SIGPIPE

Ende des Puffers ist keinem Kanal mehr zugeordnetund der Puffer ist leerread erkennt „Dateiende“ (end-of-file)

Zyklisch über Pipes verbundene Prozesseund alle Puffer vollund 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. sortPfadname (pathname), z.B. /usr/bin/sort

Verschiedene Dateiarten (Untertypen von „Datei“ in OO BS):

DatenProgrammVerzeichnis, Ordner (directory, folder)Pseudodatei (special file): E/A-Gerätu.a.

Prozess besitzt aktuelles Verzeichnis (working directory):

alle Pfadnamen, die nicht mit / beginnen,werden automatisch vorne um den Namen desaktuellen Verzeichnisses erweitert

Operation

chdir(name) mit char *namesetzt 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 Nummereines Kanals, über den auf die Datei zugegriffenwerden 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 channelerreichbaren 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)

printf formatierte Ausgabe auf stdout

fopen gepufferte Datei-Ein/Ausgabefread...

sqrt, ... mathematische Funktionen

etc. 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 einMT-Level (multi-threading level):

Unsafe, Safe, MT-Safe, Async-Signal-Safe

Unsafe: unsicherBeispiel: rand(3)

Safe: sicherBeispiel: malloc(3)

MT-Safe: sicher, mit interner NebenläufigkeitBeispiel: sqrt(3)

Async-Signal-Safe: wie MT-Safe, sogar beim Auftretenvon (Software-)Unterbrechungen(durch Unterbrechungsunterdrückungwährend kritischer Abschnitte)Beispiel: write(2)

+ Varianten