Browse Prior Art Database

Schreib-/Lese-Sperre mit schnellem Lesezugriff

IP.com Disclosure Number: IPCOM000126219D
Published in the IP.com Journal: Volume 5 Issue 7B (2005-08-10)
Included in the Prior Art Database: 2005-Aug-10
Document File: 2 page(s) / 141K

Publishing Venue

Siemens

Related People

Juergen Carstens: CONTACT

Abstract

Bei Betriebssystemsoftware eignen sich u.a. Schreib-/Lesesperren (Reader/Writer Locks) zur Serialisierung von Zugriffen mehrerer Prozesse und/oder Threads auf gemeinsame Ressourcen (z.B. Speicher). Sie gestatten den gleichzeitigen Lesezugriff und lediglich exklusiven Schreibzugriff. Handelt es sich bei den zu schuetzenden Ressourcen um kleine Datenmengen, so dominiert die Rechenzeit fuer das Setzen und Ruecksetzen der Sperre haeufig sehr stark die Zugriffszeit auf die Daten. Dies ist insbesondere fuer einzelne oder parallele Lesezugriffe ohne gleichzeitigen Schreibzugriff nachteilig, weil die Sperre gesetzt und rueckgesetzt wird, ohne das dies tatsaechlich erforderlich waere. Fuer Ressourcen mit haeufigem Lese- und nur seltenem Schreibzugriff wirkt sich dieses Problem besonders gravierend aus. Die bekannten und allgemein verwendeten Implementierungen von Schreib-/Lesesperren nutzen einfache Sperren wie beispielsweise Mutexe (Mutual Exclusion Device) oder binaere Semaphore. Unabhaengig von der Art des Zugriffs (schreibend/lesend, Sperre setzen/ruecksetzen) wird mindestens eine Sperre einmal gesetzt und wieder rueckgesetzt. Dies dominiert insbesondere bei relativ kleinen zu schuetzenden Datenmengen die Zugriffszeit.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 2

S

Schreib-/Lese-Sperre mit schnellem Lesezugriff

Idee: Jonas Hoef, DE-Muenchen

Bei Betriebssystemsoftware eignen sich u.a. Schreib-/Lesesperren (Reader/Writer Locks) zur Serialisierung von Zugriffen mehrerer Prozesse und/oder Threads auf gemeinsame Ressourcen (z.B. Speicher). Sie gestatten den gleichzeitigen Lesezugriff und lediglich exklusiven Schreibzugriff. Handelt es sich bei den zu schuetzenden Ressourcen um kleine Datenmengen, so dominiert die Rechenzeit fuer das Setzen und Ruecksetzen der Sperre haeufig sehr stark die Zugriffszeit auf die Daten. Dies ist insbesondere fuer einzelne oder parallele Lesezugriffe ohne gleichzeitigen Schreibzugriff nachteilig, weil die Sperre gesetzt und rueckgesetzt wird, ohne das dies tatsaechlich erforderlich waere. Fuer Ressourcen mit haeufigem Lese- und nur seltenem Schreibzugriff wirkt sich dieses Problem besonders gravierend aus.

Die bekannten und allgemein verwendeten Implementierungen von Schreib-/Lesesperren nutzen einfache Sperren wie beispielsweise Mutexe (Mutual Exclusion Device) oder binaere Semaphore. Unabhaengig von der Art des Zugriffs (schreibend/lesend, Sperre setzen/ruecksetzen) wird mindestens eine Sperre einmal gesetzt und wieder rueckgesetzt. Dies dominiert insbesondere bei relativ kleinen zu schuetzenden Datenmengen die Zugriffszeit.

Die Idee besteht nun darin, die Schreib-/Lesesperre fuer Ressourcen mit haeufigem Lese- und seltenem Schreibzugriff (d.h. seltenen Konflikten beim Zugriff) zu optimieren.

Die uebliche Abfolge bei einem Lesezugriff laesst sich folgendermassen beschreiben:
* Setzen der Lesesperre (vertagt den aufzurufenden Prozess/Thread im Konfliktfall, d.h. bei gleichzeitigem Schreibzugriff bis zu dessen Ende)
* Lesen der gemeinsam genutzten Ressourcen (Daten)
* Ruecksetzen der Lesesperre (weckt im Konfliktfall einen Prozess/Thread, der die Schreibsperre setzen wollte)

Die uebliche Abfolge bei einem Schreibzugriff laesst sich folgendermassen beschreiben:
* Setzen der Schreibsperre (vertagt den aufzurufenden Prozess/Thread im Konfliktfall, d.h. bei gleichzeitigem Schreib- oder Lesezugriff bis zu dessen Ende)
* Schreiben der gemeinsam genutzten Ressourcen (Daten)
* Ruecksetzen der Schreibsperre (weckt im Konfliktfall die Prozesse/Threads, die die Schreibsperre oder Lesesperre setzen wollten)

Zur Optimierung werden zusaetzlich zu den gemeinsam genu...