OPSYS 9.2: IPC-Mechanismen

Axel Rogat

Betriebssysteme und betriebssystemnahes Programmieren

9.2 IPC-Mechanismen

Es gibt wenig sinnvolle Synchronisations-Mechanismen, die in POSIX definiert sind (außer dem Record Locking, s.u.). System V definiert allerdings gleich drei davon, die sich im Lauf der Zeit über fast alle UNIX-Versionen (auch Linux) verbreitet haben:

msg_: Nachrichtenaustausch ( Message Passing)

sem_: Semaphore

shm_: gemeinsamer Speicher ( Shared Memory)

Es wird jeweils ein Satz von Operationen zur Verfügung gestellt, der aber immer eine Funktion _get (Erfragen/Anlegen eines IPC-Objekts) und eine Funktion _ctl (IPC-Kontrolle) enthält, beispielsweise

int msgget(key_t key, int flg);

Ein IPC-Objekt (aller drei Typen) wird durch einen Schlüssel vom Typ key_t (aus sys/ipc.h) identifiziert. Die _get-Funktionen verhalten sich dabei alle wie folgt:

Falls key= IPC_PRIVATE:: es wird ein neues Objekt angelegt, und die Funktion gibt seine ID zurück.
Falls key!=IPC_PRIVATE:: Falls es ein IPC-Objekt des jeweiligen Typs mit dem Schlüssel key gibt, wird dessen ID zurückgegeben.
Ansonsten, falls das Bit IPC_CREAT in flg gesetzt ist, wird ein neues Objekt kreiert und dessen ID zurückgegeben.
Sonst wird mit Fehlerstatus abgebrochen.

Bemerkungen:

Eigentlich waren die _get-Aufrufe so gedacht, daß sich die kommunizierenden Prozesse von vornherein auf einen bestimmten Schlüssel festlegen. Der erste Prozeß (z.B. ein Server) legt dann das IPC-Objekt an (mit IPC_CREAT), die anderen erfragen (ohne IPC_CREAT) dann nur noch die ID des schon existierenden Objekts.
Das funktioniert allerdings nur, wenn systemweit die Verwendung der Schlüssel festgelegt ist, so daß es nicht zu Überschneidungen kommen kann. Deshalb geht man meist einen anderen Weg:
Der Server-Prozeß legt (mit IPC_PRIVATE) das IPC-Objekt an und legt dessen ID in einer vorbestimmten Datei ab ("Lockfile"), aus der sie sich die Server-Prozesse wiederum abholen. So werden wir meist arbeiten.

Es gibt außerdem die Bibliotheksfunktion ftok (File-To-Key). Sie errechnet aus dem Pfadnamen einer existierenden Datei einen Schlüssel vom Typ key_t:

UNIX
`key_t ftok(char *pathname, char proj);`
	errechnet aus dem Pfadnamen `pathname` und dem Projektnamen `proj` einen Schlüssel vom Typ `key_t`. Es gehen dabei Gerätenummer des beteiligten Dateisystems und I-Number der Datei ein. Die Einzigartigkeit des Schlüssels im ganzen System ist nicht garantiert, aber relativ wahrscheinlich.

Alle beteiligten Prozesse müssen sich dennoch auf eine existierende Datei einigen, beispielsweise:

key_t key=ftok("/tmp/mylock",'X');
Jedes Objekt hat Besitzer und Zugriffsrechte analog zu Dateien. Insbesondere gibt es also einen Besitzer, Gruppenbesitzer, Erzeuger und Gruppen-Erzeuger. Die unteren 9 Bits von flg geben die Zugriffsrechte zu Beginn an. Besitzer und Rechte können mit _ctl-Aufrufen geändert werden.
Gelöscht werden IPC-Objekte mit einem speziellen _ctl-Aufruf (nur vom Besitzer).

Das Kommando ipcs (IPC-Status) zeigt Informationen zu allen im Moment im System befindlichen IPC-Objekte an:
------ Message Queues -------- msqid owner perms used-bytes messages 128 root 700 0 0
------ Semaphore Arrays -------- semid owner perms nsems status 3 root 0 1
------ Shared Memory Segments -------- shmid owner perms bytes nattch status 0 nobody 600 46084 6 dest
Mit den Optionen "-s", "-q" bzw. "-m" kann man die Ausgabe auf eine Sektion einschränken.
Das Kommando ipcrm löscht ein IPC-Objekt, die Berechtigung dazu vorausgesetzt. Es wird die Art des Objekts (sem, msg oder shm) und die ID angegeben:
ipcrm sem 3

9.1: FIFOs Startseite 9.3: Message Queues