Nur für Dateien im selben Verzeichnis.

Question

Unter Linux openatkann der Systemaufruf verwendet werden, um Dateien zu erstellen und ihre Existenz zu prüfen. Im Sinne des C/C++-Speichermodells entsteht durch das Erstellen einer Datei und die Überprüfung ihrer Existenz eine Synchronisationsbeziehung. Was ich wissen muss, ist, ob diese Synchronisierungen alle sequentiell konsistent zueinander sind. (Ich hoffe es natürlich, aber ich habe das nirgendwo dokumentiert gesehen.)

Gegeben seien beispielsweise die Prozesse p1 und p2 sowie die Pfade A und B:

wenn p1 dies tut: create(A), dann create(B)

und p2 macht dies: versuche zu öffnen(B), dann versuche zu öffnen(A)

und keine anderen Prozesse A oder B stören, ist es dann möglich, dass p2 B erfolgreich öffnet, aber A nicht findet?

Wenn es einen Unterschied macht, können wir davon ausgehen, dass alle Vorgänge innerhalb eines Dateisystems erfolgen.

Answer 1

Bei all den zugrunde liegenden Festplatten- und Multi-Core-CPU-Optimierungen ist es nicht unbedingt möglich, die strikte Reihenfolge einer Abfolge von Operationen zwischen zwei Prozessen zu bestimmen. Aus diesem Grund werden Semaphoren eingesetzt, wenn die Möglichkeit eines zeitabhängigen Verhaltens besteht.

Answer 2

Nur für Dateien im selben Verzeichnis.

Es gibt 6 Regeln:

1. Lesezugriff. Sperrregeln: Der Anrufer sperrt das Verzeichnis, auf das wir zugreifen. Die Sperre wird gemeinsam genutzt.

2. Objekterstellung. Sperrregeln: wie oben, aber die Sperre wird exklusiv übernommen.

3. Objektentfernung. Sperrregeln: Anrufer sperrt übergeordnetes Objekt, findet Opfer, sperrt Opfer und ruft die Methode auf. Sperren sind exklusiv.

4. rename()das istnichtverzeichnisübergreifend. Sperrregeln: Der Anrufer sperrt das übergeordnete Element und findet Quelle und Ziel. Im Falle eines Austauschs (mit dem RENAME_EXCHANGEArgument „in flags“) werden beide gesperrt. Wenn das Ziel bereits existiert, wird es auf jeden Fall gesperrt. Wenn die Quelle kein Verzeichnis ist, wird sie gesperrt. Wenn wir beide sperren müssen, sperren wir sie in der Reihenfolge des Inode-Zeigers. Rufen Sie dann die Methode auf. Alle Sperren sind exklusiv. NB: Wir könnten damit durchkommen, die gemeinsam genutzte Quelle (und das Ziel im Fall eines Austauschs) zu sperren.

5. Linkerstellung. Sperrregeln:

   • übergeordnetes Element sperren

   • Überprüfen Sie, ob die Quelle kein Verzeichnis ist

   • Quelle sperren

   • Rufen Sie die Methode auf. Alle Sperren sind exklusiv.

6. Umbenennen mehrerer Verzeichnisse. Das Schwierigste von allen. Sperrregeln:

   • Sperren Sie das Dateisystem

   • Sperren Sie die Eltern in der Reihenfolge „Vorfahren zuerst“.

   • Quelle und Ziel finden.

   • wenn das alte übergeordnete Element gleich dem Ziel ist oder ein Nachkomme davon ist, wird mit - fehlgeschlagenENOTEMPTY

   • wenn das neue übergeordnete Element gleich oder ein Nachkomme der Quelle ist, schlägt es mit - fehlELOOP

   • Wenn es sich um einen Austausch handelt, sperren Sie sowohl die Quelle als auch das Ziel.

   • Wenn das Ziel existiert, sperren Sie es. Wenn die Quelle kein Verzeichnis ist, sperren Sie sie. Wenn wir beide sperren müssen, tun Sie dies in der Reihenfolge der Inode-Zeiger.

   • rufen Sie die Methode auf. Alle ->i_rwsemwerden exklusiv genommen. Auch hier könnten wir damit durchkommen, die gemeinsame Quelle (und im Austauschfall das Ziel) zu sperren.

Die oben genannten Regeln garantieren offensichtlich, dass alle Verzeichnisse, die von der Methode gelesen, geändert oder entfernt werden, vom Anrufer gesperrt werden.

Sperren erzwingen die Linearisierbarkeit, sodass Operationenin einem einzigen Verzeichnissind vollständig geordnet. Lesezugriff (1), Objekterstellung (2) und Objektentfernung (3) erfordern jedoch keine breiteren Sperren als die Verzeichnissperre, sodass es keine Garantien für die Reihenfolge von Verzeichnisoperationen in verschiedenen Verzeichnissen gibt; verschiedene Beobachter können die linearen Historien der Verzeichnisse auf unterschiedliche Weise verschachtelt sehen.