BEZEICHNUNG¶

ÜBERSICHT¶

#include <sys/mman.h>

int mlock(const void *adr, size_t Länge);
int mlock2(const void *adr, size_t Länge, int Schalter);
int munlock(const void *adr, size_t Länge);

int mlockall(int Schalter);
int munlockall(void);

BESCHREIBUNG¶

munlock() und munlockall() führen die umgekehrte Aktion durch, d.h. entsperren den gesamten oder einen Teil des virtuellen Adressraums des aufrufenden Prozesses, sodass die Seiten im angegebenen virtuellen Adressbereich wieder ausgelagert werden können, wenn das von der Kernel-Speicherverwaltung verlangt wird.

(Ent)sperren des Speichers wird für ganze Speicherseiten durchgeführt.

RÜCKGABEWERT¶

FEHLER¶

ENOMEM

(Linux 2.6.9 und neuer) Der Aufrufende hatte eine weiche Ressourcenbegrenzung RLIMIT_MEMLOCK ungleich null, versuchte aber über diese Grenze hinaus Speicher zu sperren. Diese Grenze wird nicht erzwungen, wenn der Prozess privilegiert ist (CAP_IPC_LOCK).

ENOMEM

(Linux 2.4 und älter) Der aufrufende Prozess versuchte, mehr als die Hälfte des RAMs zu sperren.

EPERM

Der Aufrufende ist nicht privilegiert, benötigt aber zur Durchführung der angeforderten Aktionen Privilegien (CAP_IPC_LOCK).

Für mlock(), mlock2() und munlock():

EAGAIN

Ein Teil des angegebenen Adressbereichs oder der gesamte Adressbereich konnten nicht gesperrt werden.

EINVAL

Das Ergebnis der Addition adr+Länge war kleiner als adr (z. B. kann die Addition einen Überlauf verursacht haben).

EINVAL

(Nicht unter Linux) addr war kein Vielfaches der Seitengröße.

ENOMEM

Ein Teil des angegebenen Adressbereichs entspricht nicht Seiten, die in den Adressraum des Prozesses gemappt sind.

ENOMEM

Sperren oder Entsperren eines Bereiches würde dazu führen, dass die Gesamtanzahl der Mappings mit eindeutigen Attributen (z.B. gesperrt oder nicht gesperrt) das erlaubte Maximum überschreiten würde. (Beispielsweise würde das Entsperren eines Bereichs in der Mitte eines derzeit gesperrten Bereichs zu drei Mappings führen: zwei gesperrte Mappings an jedem Ende und ein entsperrtes Mapping in der Mitte.)

Für mlock2():

EINVAL

Es wurden unbekannte Schalter angegeben.

Für mlockall():

EINVAL

Es wurden entweder unbekannte Schalter angegeben oder MCL_ONFAULT wurde weder mit MCL_FUTURE noch mit MCL_CURRENT angegeben.

Für munlockall():

EPERM

(Linux 2.6.8 und älter) Der Aufrufende war nicht privilegiert (CAP_IPC_LOCK).

VERSIONEN¶

KONFORM ZU¶

mlock2() ist Linux-spezifisch.

VERFÜGBARKEIT¶

Auf POSIX-Systemen, auf denen mlockall() und munlockall() verfügbar sind, ist _POSIX_MEMLOCK in <unistd.h> als ein Wert größer als 0 definiert. (Siehe auch sysconf(3).)

ANMERKUNGEN¶

Echtzeitprozesse, die mittels mlockall() Verzögerungen durch Seitenausnahmebehandlungen vermeiden, sollten ausreichend gesperrte Stackseiten reservieren, bevor sie in die zeitkritische Phase treten, sodass durch einen Funktionsaufruf keine Seitenausnahmebehandlung entstehen kann. Dies kann durch den Aufruf einer Funktion erreicht werden, die eine ausreichend große automatische Variable (ein Feld) erzeugt und in den Speicher schreibt, in dem die Variable liegt, um diese Stackseiten zu belegen. Auf diesem Wege werden genug Seiten für den Stack gemappt und können im RAM gesperrt werden. Der Schreibvorgang stellt sicher, dass nicht einmal ein Schreib-Kopier-Seitenausnahmebehandlung in der kritischen Phase eintreten kann.

Speichersperren werden nicht an mittels fork(2) erzeugte Kindprozesse vererbt und durch einen Aufruf von execve(2) oder das Ende des Prozesses automatisch entfernt (entsperrt). Die Einstellungen MCL_FUTURE und MCL_FUTURE | MCL_ONFAULT in mlockall() werden nicht von einem Kindprozess ererbt, der mittels fork(2) erzeugt wurde und werden während eines execve(2) gelöscht.

Beachten Sie, dass fork(2) den Adressraum für eine Kopieren-beim-Schreiben-Aktion vorbereiten wird. Die Konsequenz ist, dass nachfolgende Schreibaktionen zu einer Seitenausnahmebehandlung führen werden, die wiederum hohe Latenzen für Echtzeitprozesse hervorrufen. Daher ist es essenziell, fork(2) nicht nach einer mlockall()- oder mlock()-Aktion auszuführen - selbst nicht aus einem Thread, der bei niedriger Priorität innerhalb eines Prozesses läuft, der wiederum einen Thread hat, der mit erhöhter Priorität läuft.

Die Speichersperrung wird automatisch entfernt, wenn der Adressbereich mittels munmap(2) entmappt wird.

Speichersperren werden nicht hochgezählt (»gestapelt«), das heißt, Seiten die mehrmals durch den Aufruf von mlockall(), mlock2() oder mlock() gesperrt wurden werden durch einen einzigen Aufruf von munlock() für den entsprechenden Bereich oder durch munlockall() sofort wieder freigegeben. Seiten, die an verschiedene Orte oder für verschiedene Prozesse gemappt wurden, bleiben solange im RAM gesperrt, wie sie mindestens an einem Ort oder durch einen Prozess gesperrt sind.

Wenn einem Aufruf von mlockall(), der den Schalter MCL_FUTURE nutzt, ein weiterer Aufruf folgt, der diesen Schalter nicht angibt, gehen die durch den Aufruf von MCL_FUTURE erwirkten Änderungen verloren.

Der Schalter MLOCK_ONFAULT von mlock2() und der Schalter MCL_ONFAULT von mlockall() erlaubt effizientes Speicher-Sperren für Anwendungen, die mit großen Mappings umgehen, bei denen nur ein (kleiner) Anteil von Seiten im Mapping berührt werden. In diesen Fällen würde das Sperren aller Seiten in dem Mapping eine erhebliche Einbuße für das Speicher-Sperren verursachen.

FEHLER¶

In den Linux-Kerneln 2.4.x bis einschließlich 2.4.17 bewirkte ein Fehler, dass der Schalter MCL_FUTURE von mlockall() über einen Aufruf von fork(2) vererbt wurde. Dies wurde in Kernel 2.4.18 behoben.

Seit Kernel 2.6.9 werden, falls ein privilegierter Prozess mlockall(MCL_FUTURE) aufruft und anschließend Privilegien aufgibt (die Capability CAP_IPC_LOCK verliert, weil er beispielsweise seine effektive UID auf einen von null verschiedenen Wert setzt), nachfolgende Speicherzuordnungen (z.B. mmap(2), brk(2)) fehlschlagen, wenn die Ressourcengrenze RLIMIT_MEMLOCK angetroffen wird.

SIEHE AUCH¶

KOLOPHON¶

ÜBERSETZUNG¶

Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.

Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer.