Echtzeit- und Multicore-Programmierung

Der vierte Semaphor: Multiple-Readers-Writers-Lock

08.06.2010 | Autor / Redakteur: David Kalinsky* / Martina Hafner

*David Kalinsky ist Leiter für Kundentraining bei D. Kalinsky Associates – Technical Training, einem Anbieter von Intensivseminaren für professionelle Embedded System- und Softwareentwickler. Als Dozent und Seminarleiter für Embedded-Softwarethemen hat er sich in Nordamerika, Europa und Israel einen Namen gemacht. In Deutschland ist er regelmäßiger Gastreferent beim Münchner Anbieter von technischen Trainings HILF!.

Anwender von Echtzeit-Betriebssystemen sind in der Regel mit drei Semaphor-Typen vertraut: je nach RTOS Zähl-, binäre oder Mutex-Semaphore. In vielen multicorefähigen Betriebssystemen kommt ein weiterer hinzu — der Multiple-Readers-Writers-Lock. Dieser Artikel beschreibt, wie er funktioniert und welche Anwendungsprobleme sich damit adressieren lassen.

Entwickler von Software für Multicore-Prozessoranwendungen stoßen immer häufiger auf das so genannte „Multiple-Readers-Writers“-Problem. Es tritt auf, wenn mehrere Tasks einen großen Datenbereich gemeinsam nutzen sollen. Solange eine Task in den Datenbereich schreibt, darf keine andere Task zur selben Zeit darin schreiben bzw. lesen. Diese Regelung ließe sich auch mit einem herkömmlichen Semaphor einfach umsetzen.

Im „Multiple-Readers-Writers“-Fall jedoch soll es mehreren Tasks möglich sein, gleichzeitig Daten zu lesen – vorausgesetzt, es findet aktuell kein Schreibvorgang im Datenbereich statt. Herkömmliche Semaphore bieten diese Flexibilität nicht, denn sie gewähren immer nur einem Leseprozess (Reader) Zugriff zum Datenbereich, wenn gerade keine Task schreibt. Mit diesem Ansatz lässt sich also dem Problem der Multiple-Readers-Writers nicht effizient begegnen.

Ein einfaches Anwendungsbeispiel für Multiple-Readers-Writers-Lock

Das Problem lässt sich am Beispiel einer Datenbankverwaltung für die Sitzplatzreservierung verdeutlichen: Mehrere Kunden interessieren sich für einen bestimmten Sitzplatz auf einem bestimmten Flug und wollen zur selben Zeit den Plan für die angrenzenden Sitze ansehen. Es kann also vorkommen, dass sich beispielsweise Kunden in San Francisco, Berlin und Tel Aviv alle gleichzeitig nach Sitzplätzen in der Nähe von Sitz 18D erkundigen.

Bild 1: Illustration des Beispiels Buchungssystem für Fluggesellschaft. Ein klassisches Problem von „Multiple-Readers-Writers“
Bild 1: Illustration des Beispiels Buchungssystem für Fluggesellschaft. Ein klassisches Problem von „Multiple-Readers-Writers“

Alle Kunden, die den Sitzplan sehen möchten, sollen diese Information natürlich schnellstmöglich erhalten – und zwar gleichzeitig und nicht nacheinander. Reserviert jedoch einer dieser Kunden dann tatsächlich einen oder zwei Sitzplätze, dann soll es auch nur diesem Kunden möglich sein, diese Sitze auszuwählen. Es muss verhindert werden, dass verschiedene Kunden gleichzeitig den gleichen Platz bzw. die gleichen Plätze auswählen können.

Ebenso wenig darf es möglich sein, den Sitzplan zu lesen, während die Sitzplatzreservierung gerade aktualisiert wird. Dieser Ablauf lässt sich mit einem Multiple-Readers-Writers-Lock umsetzen: Ist kein Schreibvorgang aktiv, sind mehrere Lesevorgänge gleichzeitig möglich. Während eines Schreibvorgangs dagegen ist kein gleichzeitiger Zugriff gestattet.

Multiple-Readers-Writers-Lock in Echtzeitbetriebssystemen

Der Multiple-Readers-Writers-Lock steht in immer mehr embedded Multicore-Betriebssystemen zur Verfügung - besonders in symmetrischen Multiprozessor-Betriebssystemen (SMP), deren Ursprung entweder im Bereich der herkömmlichen Single-CPU-RTOS oder in der SMP-Linux-Welt liegt. Beim Einsatz dieser Betriebssysteme können Tasks (bzw. Threads oder Prozesse) dynamisch von Core zu Core wechseln.

In bestimmten Anwendungen müssen diese Tasks gleichzeitig in gemeinsam genutzten Datentabellen oder Datenbanken lesen. Oder mehrere Tasks haben eine Producer-Consumer-Beziehung für gemeinsam genutzte Daten, und es sollen gleichzeitig mehrere Consumer Informationen erhalten.

Auf einem Multicore-Chip können verschiedene Tasks auf verschiedenen Cores mit echtem Parallelismus ablaufen (anders als beim Pseudo-Parallelismus für das Multitasking mit Single-CPU). Erhalten die Tasks die erforderlichen Daten basierend auf echtem Parallelismus, verbessert dies die Performance gegenüber dem sequentialisierten Lesen über einen „herkömmlichen“ Semaphor.

Überblick herkömmlicher Semaphor-Varianten: Zählsemaphor

Echtzeit-Betriebssysteme für Single-CPU-Systeme unterstützen für gewöhnlich die folgenden drei Semaphor-Varianten: Zählsemaphore, binäre Semaphore und Mutex-Semaphore. In unserem Multitasking-Softwaredesign erfüllt jedes seinen eigenen Zweck.

Inhalt des Artikels:

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 349652 / Software-Implementierung)

Embedded Software Engineering Report abonnieren

4 mal jährlich: Die kostenlose Pflichtlektüre für Embedded­-Software- und Systems-Entwickler, von Analyse bis Wartung und Betrieb

* Ich bin mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung und AGB einverstanden.
Spamschutz:
Bitte geben Sie das Ergebnis der Rechenaufgabe (Addition) ein.