Nicht-blockierende Synchronisation für Echtzeitsysteme

Transkript

1 Nicht-blockierende Synchronisation für Echtzeitsysteme Seminar Mobile Systeme Florian Schricker 15. März 2005 Seminarleiter: Prof. Dr. Dieter Zöbel 1

2 INHALTSVERZEICHNIS INHALTSVERZEICHNIS Inhaltsverzeichnis 1 Einleitung 3 2 Synchronisation Multi-Threading Mutual Exclusion Deadlocks[2] Synchronisation und Echtzeitsysteme Mutual Exclusion und Echtzeitsysteme Fazit: Anforderungen an Synchronisation in Echtzeitsystemen 6 4 Nicht-blockierende Synchronisation für Echtzeitsysteme Wait-free Synchronization Lock-free Synchronisation CAS

3 1 Einleitung 1 EINLEITUNG In letzter Zeit haben nicht-blockierende Synchronisationstechniken in der Forschung und der praktischen Anwendung Einzug gehalten. Dabei gibt es zwei Herangehensweisen: Entweder werden Algorithmen in nicht-blockierende Algorithmen transformiert oder es wird versucht eziente Datenstrukturen zu entwerfen, die sich ohne Blockierung synchronisieren lassen. Basierend auf ezienten, nicht-blockierenden Datenstrukturen stellt [1] eine Vorgehensweise vor, ein nicht-blockierendes Echtzeitsystem zu bauen: den Fiasco Mikrokernel. Grundlage dieser Ausarbeitung ist die Dissertation von Michael Hohmuth, Pragmatic nonblocking synchronization for real-time systems [1]. Es wird zuerst beschrieben, was Synchronisation im Zusammenhang mit Betriebssystemen generell bedeutet, um nicht-blockierende Synchronisation einordnen zu können (Kapitel 2). Im Anschluss daran wird Synchronisation allgemein bei Echtzeit-Systemen (Kapitel 3) und die nicht-blockierende Synchronisation im Speziellen (Kapitel 4) vorgestellt. 3

4 2 SYNCHRONISATION 2 Synchronisation Moderne Betriebssysteme sind aufgeteilt in eine Reihe von Prozessen, die von einem Scheduler zur Ausführung gebracht werden. Um die Illusion einer gleichzeitigen Ausführung mehrerer Prozesse auf einem Ein-Prozessor- System zu erreichen, müssen Prozesse jederzeit vom Scheduler unterbrochen werden können. Dies wird als präemptives Multi-Tasking bezeichnet. 2.1 Multi-Threading Prozesse selbst bestehen aus mindestens einem, meist aber mehreren Threads, die ebenfalls dem Scheduler zur Ausführung übergeben werden - das sogenannte Multi-Threading. Die Threads eines Prozesses arbeiten zusammen auf demselben (virtuellen) Speicher, der dem Prozess vom System zur Verfügung gestellt wurde. Dieser gemeinsam genutzte Speicher muss vor ungewolltem Zugri der Threads geschützt werden, der Zugri also synchronisiert werden, da sonst Inkonsistenzen auftreten können. Synchronisation wird erreicht, indem der Zugri auf eine gemeinsam verwendete Ressource nur einem der beteiligten Threads exklusiv ermöglicht wird. Ein Thread, der exklusiven Zugri auf eine gemeinsame Ressource erhalten hat, bendet sich in seinem kritischen Bereich. Kritisch in dem Sinne, dass der exklusive Zugri nicht durch andere Threads unterbrochen werden darf. 2.2 Mutual Exclusion Die herkömmliche Technik zur Synchronisation von Threads ist die Mutual Exclusion 1. Kritische Bereiche werden bei der Mutual Exclusion durch Locks 2 geschützt. Will ein Thread X auf eine Ressource zugreifen, so versucht er, das zur Ressource gehörende Lock zu besetzen. Ist das Lock frei, erhält X das Lock und somit exklusiven Zugri auf die Ressource. Nach dem Zugri gibt X die Ressource wieder frei, indem er das Lock freigibt. Andere Threads, die auf das Lock zugreifen wollen und das Lock ihrerseits erhalten wollen, während X exklusivem Zugang gewährt wird, warten auf die Freigabe durch X. Ein Vorteil dessen ist, dass wartende Threads vom Scheduler deaktiviert werden können, um andere Threads auszuführen. 1 Mutual Exclusion: gegenseitiges Ausschlieÿen 2 Lock: Schloss, Semaphore 4

5 2.3 Deadlocks[2] 2 SYNCHRONISATION 2.3 Deadlocks[2] Deadlocks sind ein klassischer Problemfall der Mutual Exclusion, bei der Threads auf die Freigabe einer Ressource warten, möglicherweise ohne sie jemals zu erhalten [ref:en.wikipedia.org/wiki/deadlock]. Da es keinen generellen Ansatz zur Vermeidung von Deadlocks bei Mutual Exclusion gibt, ist es immer Aufgabe des Entwicklers, Deadlocks zu vermeiden. Kondition für Deadlocks 1. Durch Mutual Exclusion geschützte Ressourcen sind nur von einem Thread zugreifbar. 2. Threads warten auf die Freigabe von Ressourcen, haben aber bereits selbst exklusiv Ressourcen erhalten Nur der Thread, der das Lock auf eine Ressource erhalten hat, kann diese auch wieder freigeben. 4. Zirkuläres Deadlock; zwei Threads warten gegenseitig auf die Freigabe einer Ressource, die der andere Thread hält. 3 Hold and wait 5

6 3 SYNCHRONISATION UND ECHTZEITSYSTEME 3 Synchronisation und Echtzeitsysteme Das obige Kapitel erklärt, dass die Synchronisation gemeinsam genutzter Ressourcen in einer Multi-Threading-Umgebung unbedingt notwendig ist. In klassischen Echtzeit-Scheduling-Methoden wurde Synchronisation aber bisher ignoriert. EDF 4 und RMS 5 erlaubten keine gemeinsam genutzten Ressourcen. 3.1 Mutual Exclusion und Echtzeitsysteme Echtzeitsysteme mit klassischen Schedulern wie EDF oder RMS sind Prioritätenbasiert. Durch Prioritäten wird sichergestellt, dass wichtige Prozesse, insbesondere Event-Handler 6, vom Scheduler schnellstmöglich ausgeführt werden. Diese wichtige Anforderung kann durch die klassische Synchronisation, der Mutual Exclusion, nicht erfüllt werden. Werden gemeinsam verwendete Ressourcen durch Mutual Exclusion gesichert, kann die sogenannte Priority- Inversion auftreten. Priority-Inversion Priority-Inversion tritt immer dann auf, wenn ein Thread Y mit niedriger Priorität eine Ressource belegt, die von einem Thread X mit höherer Priorität benötigt wird. In diesem Fall ist die hohe Priorität von X eektiv invertiert auf die niedrige Priorität von Y, denn X kann nicht zur Ausführung gebracht werden. Das Problem der Priority-Inversion steigert sich weiter, wenn ein Thread Z mittlerer Priorität anstelle von X vom Scheduler zur Ausführung gebracht wird. Dies könnte geschehen, wenn zum Beispiel die Ausführungszeit von Y abgelaufen ist. 3.2 Fazit: Anforderungen an Synchronisation in Echtzeitsystemen Es ist es wichtig, dass hoch-priorisierte Threads vom Scheduler eines Echtzeitsystems möglichst schnell zur Ausführung gebracht werden können. Diese wichtige Anforderung kann für die Synchronistion nur erfüllt sein, wenn sie voll präemptiv ist und Priority-Inversion verhindert. Beides wird von der Synchronisation durch Mutual Exclusion nicht erfüllt. 4 EDF: Earliest Deadline First 5 RMS: Rate-Monotonic Scheduling 6 Zum Beispiel könnte ein Event-Handler die Auslösung eines Airbags veranlassen. 6

7 4 NICHT-BLOCKIERENDE SYNCHRONISATION FÜR ECHTZEITSYSTEME 4 Nicht-blockierende Synchronisation für Echtzeitsysteme Unter nicht-blockierender Synchronisation versteht man Protokolle zur gemeinsamen Verwendung von Ressourcen. Sie verhindert, dass beim Zugri Blockierungen auftreten. Nicht-blockierende Synchronisation ist voll präemptiv und es tritt keine Priority-Inversion auf. Es gibt zwei Arten von nicht-blockierender Synchronisation: Wait-free und Lock-free Synchronisation, die im Folgenden vorgestellt werden. 4.1 Wait-free Synchronization Bei dieser Art nicht-blockierender Synchronisation blockieren Threads nicht beim Zugri auf eine belegte Ressource, sondern unterstützen den Blocker. Jede Ressource wird zu diesem Zweck über einen Helfer-Stack gesichert. Ablauf beim Zugri auf eine gemeinsam verwendete Ressource Wenn ein hoch-priorisierter Thread X beim Zugri auf eine gemeinsam verwendete Ressource erkennt, dass diese von einem niedrig-priorisierten Thread Y gehalten wird, hilft X dem Thread Y. Das heisst: 1. X fügt sich dem Helfer-Stack der Ressource zu. 2. Anstatt zu warten gibt X seine CPU-Zeit an Y weiter, um schnellstmöglich Zugri auf die Ressource zu erlangen. Das bedeutet eektiv, dass X seine Priorität an Y überträgt. Durch die vorübergehende Erhöhung der Priorität von Y ist sichergestellt, dass kein anderer Thread vom Scheduler zur Ausführung gebracht wird. Diese Vorgehensweise wird als Priority-Inheritance bezeichnet. 3. Wenn Y seinen Zugri auf die Ressource beendet hat Der Helfer-Stack hat einen entscheidenden Vorteil: Da bei einem Echtzeitsystem der Scheduler Threads Prioritäten-basiert zur Ausführung bringt, ist der höchst-priorisierte Thread immer der erste im Helfer-Stack. Niederpriorisierte Threads können nicht davor gestellt werden und die CPU erhalten; somit ist auch das Problem der Priority-Inversion bei der Wait-free Synchronisation gelöst. 7

8 4 NICHT-BLOCKIERENDE SYNCHRONISATION FÜR 4.2 Lock-free Synchronisation ECHTZEITSYSTEME 4.2 Lock-free Synchronisation Lock-free Synchronisation funktioniert ohne die Notwendigkeit, gemeinsam genutzte Ressourcen durch Locks zu sichern. Dies wird ermöglicht, indem Threads das Berechnungsergebnis ihrer kritischen Bereichs vorbereiten und anschlieÿend versuchen, das Ergebnis in einem Schritt zu übertragen. Ermöglicht wird Lock-free Synchronisation durch den atomaren Maschinenbefehl CAS - Compare-And-Swap. Durch CAS, anschlieÿend im Detail vorgestellt, können Konikte erkannt werden, wenn zwei Threads gleichzeitig versuchen, eine Speicheradresse zu verändern. Durch Compare wird sichergestellt, dass an der Speicheradresse der erwartete Wert vorliegt. Ist dies der Fall, wird das Berechnungsergebnis übertragen - Swap. Hat sich die Speicheradresse in der Zwischenzeit, zum Beispiel durch einen anderen Thread, geändert, so schlägt Compare fehl und die Operation wird neu gestartet (Retry-Loop). Lock-free Synchronisation mit CAS hat folgende Vorteile: Ohne Locks kann es nie zu Deadlocks kommen. Threads sind besser voneinander isoliert, weil keine Locks auf Ressourcen von gecrashten Threads gehalten werden können. Daraus folgt eine bessere Fehlertoleranz und Robustheit des Systems. Lock-free Synchronisation eignet sich gut für Multi-Prozessor-Systeme. 4.3 CAS CAS ist eine Vorbedingung für die Lock-free Synchronisation und arbeitet auf typ-sicherem Speicher [ref:usenix7]. Durch CAS werden eine Reihe von Datenstrukturen ermöglicht, die dadurch Lock-free synchronisiert werden. Diese sind Zähler Stacks FIFO Queue Liste (single-linked) Um komplexere Datenstrukturen zu ermöglichen, wird das sogenannte MW- CAS (Multi-Word-Compare-And-Swap) benötigt. Bei MWCAS werden zwei Speicherstellen gleichzeitig überprüft und gegebenenfalls neu gesetzt. MW- CAS ist kein atomarer Prozessorbefehl der x86-familie und muss deshalb als 8

9 4.3 CAS 4 NICHT-BLOCKIERENDE SYNCHRONISATION FÜR ECHTZEITSYSTEME Software-Implementation bereitgestellt werden. In dieser Ausarbeitung wird MWCAS nicht behandelt. Im Folgenden wird CAS in Form einer C-Beispielimplementation vorgestellt und eine Lock-free Stack-Implementation damit realisiert. CAS in C bool CAS(int* address, int old_val, int new_val) if (*address == old_val) *address == new_val; return TRUE; } else return FALSE; } Lock-free Stack mit CAS in C Ein Stack stellt die Operationen push (füge dem Stack ein neues Element hinzu) und pop (entferne das oberste Element vom Stack und gebe es zurück) zur Verfügung. Die Datenstruktur des Stacks ist ein struct: struct StackElement int value; struct StackElement* next; } Push-Operation Bei der Push-Operation wird eine Endlos-Schleife ausgeführt. In dieser Schleife wird der next-pointer des neuen Stack-Elements auf das oberstes Stack-Element (top) gesetzt. Eine CAS-Operation überprüft anschlieÿend, ob das oberste Stackelement verändert wurde. Ist dies nicht der Fall, so wird das neue Stackelement als top gesetzt und die Schleife verlassen. Wurde top, zum Beispiel durch einen anderen Thread, verändert, so wird die Schleife neu gestartet und der next-pointer auf das neue, oberste Stack-Element gesetzt. 9

10 4.3 CAS 4 NICHT-BLOCKIERENDE SYNCHRONISATION FÜR ECHTZEITSYSTEME void push(stackelement* top, StackElement* new) do ADDR a = ⊤ new->next = *top; } while (!CAS(&top, a, &(new->next))); Pop-Operation Die Pop-Operation verläuft ähnlich der Push-Operation. Dabei wird die Adresse des top-elementes sowie die Adresse des neuen top- Elementes lokal gespeichert. Die CAS-Operation überprüft, ob sich das top- Element in der Zwischenzeit verändert hat und setzt das next-element von top als neues, oberstes Stackelement. Schlägt der Vergleich fehl, so wird die Operation neu gestartet. StackElement* pop(stackelement* top) if (top->next!= NULL) ADDR topaddr, next; do topaddr = ⊤ next = &(top->next); } while(!cas(&(top->next), next, next)); *top = next; return topaddr; } else return NULL; } Fazit Lock-free Synchronisation Obwohl die Lock-free Synchronisation wichtige Vorteile bietet (keine Priority-Inversion, keine Deadlocks) und sich so generell gut für Echtzeitsysteme zu eignen scheint, gibt es doch Schwierigkeiten. Diese müssen beim Einsatz der Lock-free Synchronisation berücksichtigt werden: CAS muss als Maschinenbefehl vorhanden sein. 10

11 4.3 CAS 4 NICHT-BLOCKIERENDE SYNCHRONISATION FÜR ECHTZEITSYSTEME MWCAS ist oft (z.b. bei der x86-familie) nicht als atomarer Prozessorbefehl vorhanden und muss aufwändig als Software-Lösung bereitgestellt werden. Schlägt das Compare fehl, so muss das Ergebnis in einem Retry-Loop neu berechnet werden. Für höchst-priorisierte Threads eines Echtzeitsystems ist dies zwar nur maximal einmal notwendig, es kann aber keine generelle Aussage für nieder-priorisierte Threads getroen werden (aktuelle Forschungen versuchen dieses Problem zu lösen [ref]). Lock-free Synchronisation funktioniert nur durch CAS- / MWCAS- Datenstrukturen. Komplexere Algorithmen müssen dahingehend angepasst werden oder gänzlich neu entwickelt werden. 11

12 LITERATUR LITERATUR Literatur [1] Michael Hohmuth: Pragmatic nonblocking synchronization for real-time systems, Dresden University of Technology, 10/2002 [2] Wikipedia.org - Deadlocks, 12