Welche Arten von Linux-Sperren gibt es?

Arten von Linux-Sperren: 1. Mutex (Mutex-Sperre), die verwendet wird, um sicherzustellen, dass jeweils nur ein Thread auf das Objekt zugreifen kann; 2. rwlock (Lese-/Schreibsperre), die in Lesesperre und Schreibsperre unterteilt ist. Geeignet für Situationen, in denen die Häufigkeit des Lesens von Daten viel größer ist als die Häufigkeit des Schreibens von Daten. 3. Spinlock (Spinlock), es kann immer nur ein Thread auf das Objekt zugreifen. 4. Seqlock (sequentieller Lock), der zur Unterscheidung verwendet wird Beim Lesen und Schreiben gibt es viele Lesevorgänge und wenige Schreibvorgänge. Die Priorität von Schreibvorgängen ist höher als die von Lesevorgängen.

Die Betriebsumgebung dieses Tutorials: Linux7.3-System, Dell G3-Computer.

Mehrere Sperrmechanismen in Linux

Mutex: Mutex

Mutex: Mutex, wird verwendet, um sicherzustellen, dass jeweils nur ein Thread auf das Objekt zugreifen kann. Wenn der Sperrenerfassungsvorgang fehlschlägt, geht der Thread in den Ruhezustand und wird aufgeweckt, während er auf die Freigabe der Sperre wartet.

Lese-/Schreibsperre: rwlock

 Lese-/Schreibsperre: rwlock, unterteilt in Lesesperre und Schreibsperre. Im Lesevorgang kann es mehreren Threads gestattet werden, gleichzeitig Lesevorgänge abzurufen. Es kann jedoch immer nur ein Thread gleichzeitig die Schreibsperre erhalten. Andere Threads, denen es nicht gelingt, die Schreibsperre zu erhalten, gehen in den Ruhezustand über, bis sie bei Aufhebung der Schreibsperre aktiviert werden.

Hinweis: Schreibsperren blockieren andere Lese- und Schreibsperren. Wenn ein Thread eine Schreibsperre erhält und schreibt, kann die Lesesperre nicht von anderen Threads erworben werden; Autoren haben Vorrang vor Lesern (sobald es einen Schreiber gibt, müssen nachfolgende Leser warten, und Schreiber erhalten beim Aufwachen Vorrang).

• Anwendbar auf Situationen, in denen die Häufigkeit des Lesens von Daten viel größer ist als die Häufigkeit des Schreibens von Daten.

Spin-Lock: Spinlock

  Spin-Lock: Spinlock, immer nur ein Thread kann auf das Objekt zugreifen. Wenn der Sperrenerfassungsvorgang jedoch fehlschlägt, geht er nicht in den Ruhezustand, sondern dreht sich an Ort und Stelle, bis die Sperre aufgehoben wird. Dadurch wird der Verbrauch von Threads vom Ruhezustand bis zum Aufwachen eingespart, was die Effizienz in Umgebungen mit kurzer Sperrzeit erheblich verbessert. Wenn die Sperrzeit jedoch zu lang ist, werden viele CPU-Ressourcen verschwendet.

RCU

  RCU: Beim Ändern von Daten müssen Sie zuerst die Daten lesen, dann eine Kopie erstellen und die Kopie ändern. Aktualisieren Sie nach Abschluss der Änderung die alten Daten auf neue Daten.

Bei Verwendung von RCU benötigen Lesegeräte nahezu keinen Synchronisierungsaufwand. Sie müssen weder Sperren erhalten noch atomare Anweisungen verwenden, was keine Sperrenkonkurrenz verursacht, sodass keine Deadlock-Probleme berücksichtigt werden müssen. Der Synchronisierungsaufwand des Autors ist relativ groß. Er muss die geänderten Daten kopieren und einen Sperrmechanismus verwenden, um die Änderungsvorgänge anderer Autoren zu synchronisieren und zu parallelisieren. Es ist sehr effizient, wenn eine große Anzahl von Lesevorgängen und eine kleine Anzahl von Schreibvorgängen vorhanden sind.

Semaphor: Semaphor

Das Semaphor des Linux-Kernels ist in Konzept und Prinzip dasselbe wie das SystemV-IPC-Mechanismus-Semaphor im Benutzermodus, kann jedoch niemals außerhalb des Kernels verwendet werden und ist daher nicht dasselbe wie SystemV Der IPC-Mechanismus hat nichts mit Semaphoren zu tun.

Das Semaphor muss beim Erstellen einen Anfangswert festlegen, was bedeutet, dass mehrere Aufgaben gleichzeitig auf die durch das Semaphor geschützten gemeinsamen Ressourcen zugreifen können. Ein Anfangswert von 1 wird dort zu einem Mutex (Mutex). Es kann immer nur eine Aufgabe gleichzeitig auf gemeinsame Ressourcen zugreifen, die durch Semaphoren geschützt sind. Wenn eine Aufgabe auf eine gemeinsam genutzte Ressource zugreifen möchte, muss sie zunächst ein Semaphor abrufen. Durch den Vorgang zum Abrufen des Semaphors wird der Wert des Semaphors um 1 reduziert. Wenn der aktuelle Wert des Semaphors eine negative Zahl ist, bedeutet dies, dass das Semaphor vorhanden ist kann nicht abgerufen werden und die Aufgabe muss dort angehalten werden. Die Warteschlange des Semaphors wartet darauf, dass der Semaphor verfügbar ist. Wenn der aktuelle Semaphorwert eine nicht negative Zahl ist, bedeutet dies, dass der Semaphor abgerufen werden kann, also die gemeinsam genutzten Ressourcen Auf die durch das Semaphor geschützten Daten kann sofort zugegriffen werden. Nachdem die Aufgabe den Zugriff auf die durch das Semaphor geschützte gemeinsame Ressource abgeschlossen hat, muss sie das Semaphor freigeben, indem sie 1 zum Wert des Semaphors addiert. Wenn der Wert des Semaphors eine nicht positive Zahl ist, zeigt dies an Es gibt eine Aufgabe, die auf das aktuelle Semaphor wartet. Daher werden auch alle Aufgaben aktiviert, die auf dem Semaphor warten.

rw_semaphore (Semaphor lesen und schreiben)

Lese-/Schreibsemaphore unterteilen Besucher, entweder Leser oder Schreiber. Leser können nur die durch das Lese-/Schreibsemaphor geschützten gemeinsamen Ressourcen lesen und darauf zugreifen, während das Lese-/Schreibsemaphor beibehalten wird, außer wenn es lesen und möglicherweise schreiben muss. Es muss als Autor klassifiziert werden, bevor es auf freigegebene Ressourcen zugreifen kann. Autoren können auf Leser zurückgestuft werden, wenn sie feststellen, dass sie keinen Schreibzugriff benötigen. Es gibt keine Begrenzung für die Anzahl der Leser, die ein Lese-Schreib-Semaphor gleichzeitig haben kann, was bedeutet, dass beliebig viele Leser gleichzeitig über einen Lese-Schreib-Semaphor verfügen können. Wenn ein Lese-/Schreib-Semaphor derzeit nicht im Besitz eines Autors ist und kein Autor darauf wartet, dass ein Leser das Semaphor freigibt, kann jeder Leser das Lese-/Schreib-Semaphor erfolgreich erwerben. Andernfalls muss der Leser angehalten werden, bis der Autor das Semaphor freigibt Semaphor. Wenn ein Lese-/Schreibsemaphor derzeit nicht im Besitz eines Lesers oder Schreibers ist und keine Schreiber auf das Semaphor warten, kann ein Schreiber das Lese-/Schreibsemaphor erfolgreich erwerben. Andernfalls wird der Schreiber suspendiert, bis keine Besucher mehr vorhanden sind. . Daher ist der Autor exklusiv und exklusiv.
Es gibt zwei Implementierungen von Lese- und Schreibsemaphoren. Eine ist universell und hängt nicht von der Hardwarearchitektur ab. Daher ist für das Hinzufügen einer neuen Architektur keine erneute Implementierung erforderlich. Der Nachteil ist jedoch die geringe Leistung und der hohe Aufwand bei der Beschaffung Das andere ist architekturbezogen und weist daher eine hohe Leistung auf. Der Aufwand für das Erfassen und Freigeben von Lese- und Schreibsemaphoren ist gering. Das Hinzufügen einer neuen Architektur erfordert jedoch eine Neuimplementierung. Während der Kernel-Konfiguration können Sie mithilfe von Optionen steuern, welche Implementierung verwendet wird.

Lese- und Schreibsemaphor: rw_semaphore

Der Lese- und Schreibsemaphor unterteilt die Besucher, entweder Leser oder Schreiber, nur, indem er den Lese- und Schreibsemaphor auf eine gemeinsam genutzte Ressource aufrechterhält. Wenn für eine Aufgabe zusätzlich zum Lesen Schreibzugriff erforderlich ist, muss sie als Schreibzugriff eingestuft werden. Sie muss vor dem Zugriff auf die freigegebene Ressource den Schreibzugriff erhalten. Der Schreibzugriff kann auf den Lesezugriff herabgestuft werden. Es gibt keine Begrenzung für die Anzahl der Leser, die ein Lese-Schreib-Semaphor gleichzeitig haben kann, was bedeutet, dass beliebig viele Leser gleichzeitig ein Lese-Schreib-Semaphor besitzen können. Wenn ein Lese-/Schreib-Semaphor derzeit nicht im Besitz eines Autors ist und kein Autor darauf wartet, dass ein Leser das Semaphor freigibt, kann jeder Leser das Lese-/Schreib-Semaphor erfolgreich erwerben. Andernfalls muss der Leser angehalten werden, bis der Autor das Semaphor freigibt Semaphor. Wenn ein Lese-/Schreibsemaphor derzeit nicht im Besitz eines Lesers oder Schreibers ist und keine Schreiber auf das Semaphor warten, kann ein Schreiber das Lese-/Schreibsemaphor erfolgreich erwerben. Andernfalls wird der Schreiber suspendiert, bis keine Besucher mehr vorhanden sind. . Daher ist der Autor exklusiv und exklusiv.

Es gibt zwei Implementierungen von Lese- und Schreibsemaphoren. Eine davon ist universell und hängt nicht von der Hardwarearchitektur ab. Daher erfordert das Hinzufügen einer neuen Architektur keine erneute Implementierung, der Nachteil ist jedoch die geringe Leistung und der Aufwand für die Beschaffung Das Freigeben von Lese- und Schreibsemaphoren ist groß; das andere ist architekturbezogen, daher ist die Leistung hoch und der Aufwand für das Erfassen und Freigeben von Lese- und Schreibsemaphoren gering, aber das Hinzufügen einer neuen Architektur erfordert eine Neuimplementierung. Während der Kernel-Konfiguration können Sie mithilfe von Optionen steuern, welche Implementierung verwendet wird.

seqlock**** (sequentielle Sperre)

wird in Situationen verwendet, in denen Lesen und Schreiben unterschieden werden können, es viele Lesevorgänge und wenige Schreibvorgänge gibt und die Priorität von Schreibvorgängen höher ist als die von Lesevorgängen Operationen. Die Implementierungsidee von seqlock besteht darin, eine steigende Ganzzahl zur Darstellung der Sequenz zu verwenden. Wenn der Schreibvorgang in den kritischen Abschnitt eintritt, sequenzieren Sie ++; wenn Sie den kritischen Abschnitt verlassen, wiederholen Sie sequenz++.

Der Schreibvorgang muss außerdem eine Sperre erhalten (z. B. Mutex). Diese Sperre wird nur für den gegenseitigen Schreib-/Schreibausschluss verwendet, um sicherzustellen, dass höchstens ein Schreibvorgang gleichzeitig ausgeführt wird. Wenn die Sequenz eine ungerade Zahl ist, bedeutet dies, dass ein Schreibvorgang ausgeführt wird. Zu diesem Zeitpunkt muss der Lesevorgang warten, bis die Sequenz eine gerade Zahl wird, um in den kritischen Abschnitt zu gelangen. Wenn ein Lesevorgang in den kritischen Abschnitt eintritt, muss der Wert der aktuellen Sequenz aufgezeichnet werden. Wenn er den kritischen Abschnitt verlässt, vergleichen Sie die aufgezeichnete Sequenz mit der aktuellen Sequenz. Wenn sie nicht gleich sind, bedeutet dies, dass ein Schreibvorgang stattgefunden hat Während der Lesevorgang in den kritischen Abschnitt gelangt ist, ist der Lesevorgang ungültig und muss zurückgegeben und erneut versucht werden.

Seqlock-Schreiben muss sich gegenseitig ausschließen. Das Anwendungsszenario von seqlock selbst ist jedoch eine Situation, in der mehr gelesen und weniger geschrieben wird und die Wahrscheinlichkeit eines Schreibkonflikts sehr gering ist. Es gibt hier also grundsätzlich keinen Leistungsverlust beim Write-Write-Mutex. Die Lese- und Schreibvorgänge müssen sich nicht gegenseitig ausschließen. Das Anwendungsszenario von seqlock besteht darin, dass Schreibvorgänge Vorrang vor Lesevorgängen haben. Bei Schreibvorgängen gibt es fast keine Blockierung (es sei denn, es tritt ein Ereignis mit geringer Wahrscheinlichkeit wie ein Schreib-Schreib-Konflikt auf) und es ist nur die zusätzliche Aktion von sequence++ erforderlich. Der Lesevorgang muss nicht blockiert werden, es ist jedoch ein erneuter Versuch erforderlich, wenn ein Lese-/Schreibkonflikt festgestellt wird. Eine typische Anwendung von seqlock ist die Aktualisierung der Uhr. Im System erfolgt alle 1 Millisekunde ein Takt-Interrupt, und der entsprechende Interrupt-Handler aktualisiert die Uhr (Schreibvorgang).

Das Benutzerprogramm kann Systemaufrufe wie gettimeofday aufrufen, um die aktuelle Uhrzeit abzurufen (Lesevorgang). In diesem Fall kann die Verwendung von seqlock verhindern, dass zu viele gettimeofday-Systemaufrufe den Interrupt-Handler blockieren (dies wäre der Fall, wenn Lese-/Schreibsperren anstelle von seqlock verwendet würden). Der Interrupt-Handler hat immer Priorität, und wenn der Systemaufruf gettimeofday damit in Konflikt steht, spielt es keine Rolle, ob das Benutzerprogramm wartet.

Der Unterschied zwischen Mutex-Sperren und Lese-/Schreibsperren:

1) Lese-/Schreibsperren unterscheiden zwischen Lesern und Schreibern, während Mutex-Sperren nicht unterscheiden

2) Mutex-Sperren erlauben nur einem Thread gleichzeitig den Zugriff auf das Objekt , unabhängig vom Lesen oder Schreiben; Eine Lese-/Schreibsperre lässt nur einen Schreiber gleichzeitig zu, erlaubt jedoch mehreren Lesern, das Objekt gleichzeitig zu lesen.

Verwandte Empfehlungen: „Linux-Video-Tutorial“

Das obige ist der detaillierte Inhalt vonWelche Arten von Linux-Sperren gibt es?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!