5 Deadlock-Handling
5.1 Auftreten von Deadlocks und Deadlock-Handling-Strategien
Deadlocks treten nur auf, wenn mehrere bestimmte Bedingungen gleichzeitig erfüllt sind. Auf der Grundlage dieser Bedingungen werden Strategien zu Vermeidung oder Beseitigung von Deadlocks zu entwickelt. In Abschnitt 5.1.1 werden die Bedingungen für das Auftreten von Deadlocks im Allgemeinen identifiziert. Anschließend werden in Abschnitt 5.1.2 drei alternative Strategien des Deadlock-Handlings mit ihren Vor- und Nachteilen vorgestellt. Eine Übertragung der allgemeinen Prinzipien auf die Anwen-dungsumgebung des Containerterminals erfolgt in Abschnitt 5.1.3.
5.1.1 Bedingungen für das Auftreten von Deadlocks
Das Deadlock-Problem ist laut Coffman et al. (1971) „ein logisches Problem, das in verschiedenen Zusammenhängen auftreten kann“.17 Bevor man also Strategien zum Umgang mit Deadlocks für ein spezifisches Problem entwickelt, ist es sinnvoll, die all-gemeinen Merkmale von Deadlocks genauer zu betrachten. Allgemein durchgesetzt hat sich die Sichtweise von Coffman et al. (1971) und Liu und Hung (2001), nach der ein Deadlock genau dann auftritt, wenn folgende 4 Bedingungen gleichzeitig erfüllt sind:
(1) “mutual exclusion” condition: Keine Ressource kann von mehr als einem Prozess gleichzeitig benutzt werden.
(2) “wait for” condition: Prozesse blockieren einmal zugewiesene Ressourcen, wäh-rend sie auf weitere Ressource warten.
(3) “no preemption” condition: Ressourcen sind nicht verfügbar, bevor sie nicht von dem Prozess freigegeben werden, der sie gerade benutzt.
17 Im Original: „a logical problem that may arise in different contexts“.
(4) “circular wait” condition: Es gibt einen Zykel (= geschlossenen Kreis) von Prozessen, so dass jeder Prozess innerhalb dieses Zykels eine oder mehrere Res-sourcen blockiert, die von anderen Prozessen benötigt werden.
Jeder Ansatz zum Deadlock-Handling zielt darauf ab, mindestens eine dieser Bedingun-gen zu verletzen oder sicherzustellen, dass alle vier BedingunBedingun-gen niemals gleichzeitig erfüllt sein können. Da die erste Bedingung für die meisten Systeme erfüllt ist, stehen die letzten drei Bedingungen im Mittelpunkt der Forschung. Der übliche Weg, die zweite Bedingung zu vermeiden, ist zu fordern, dass ein Prozess schon zu Beginn alle Ressourcen anfordert, die er zu seiner Durchführung benötigt. Ein bekanntes Beispiel für diese Strategie ist der Banker’s Algorithmus, wie er z.B. von Kim et al. (1997) vor-geschlagen wird. Bedingung 3 kann außer Kraft gesetzt werden, wenn es aus techni-scher Sicht möglich ist, dass ein Prozess alle gerade benutzten Ressourcen freigibt, sobald weitere angeforderte Ressourcen nicht bewilligt werden. Das ist jedoch in der Regel nicht möglich. Schließlich kann das Entstehen eines Zykels wie in Bedingung 4 gefordert verhindert werden, indem man eine lineare Ordnung der Ressourcen etabliert.
Ein Prozess darf dann nur Ressourcen anfordern, die in dieser Ordnung niedriger stehen als die gerade benutzten Ressourcen.
5.1.2 Strategien des Deadlock-Handlings
Generell können drei Arten von Strategien im Umgang mit Deadlocks angewendet wer-den (vgl. Venkatesh und Smith, 2003 sowie und Liu und Hung, 2001): Deadlock-Pre-vention, Deadlock-Avoidance und Deadlock-Detection-and-Resolution.
Deadlock-Prevention ist eine Offline-Strategie, die darauf ausgerichtet ist, jegliche Si-tuation zu verhindern, in der ein Deadlock entstehen kann. Dieses Ziel wird üblicher-weise durch die Festlegung einiger allgemeiner Regeln erreicht, die sicherstellen, dass nicht alle 4 Bedingungen gleichzeitig erfüllt sein können. Zur Veranschaulichung be-trachte man Abbildung 5-3.
Abbildung 5-3: Strategien des Deadlock-Handlings
In diesem Beispiel sind die den Fluss überspannenden Brücken so schmal, dass zwei Autos nicht aneinander vorbeifahren können. Die Aufgabe der Deadlock-Handling-Strategien besteht in diesem Beispiel darin sicherzustellen, dass der Verkehr trotzdem nicht zum Stehen kommt. Eine typische Vorgehensweise der Deadlock-Prevention ist in Abbildung 5-3(a) dargestellt – die Brücken sind als Einbahnstraßen ausgeschildert.
Damit wird von Vornherein ein Eintreten einer der notwendigen Bedingungen für Deadlocks – der „circular-wait“ condition – verhindert. Zu der Situation, dass sich zwei Autos auf der Brücke treffen, und keines der beiden kommt vorwärts, kann es aufgrund der Ausschilderung nicht kommen.
Im Gegensatz dazu beinhaltet Deadlock-Avoidance eine dynamische Zuweisung der Ressourcen unter Benutzung einer geeigneten Kontrollpolitik, mit der Deadlock-Situa-tionen vermieden werden, die durch das nächste Ereignis im System entstehen. Die Verkehrsregelung durch Ampeln in Abbildung 5-3(b) ist ein Beispiel für diese Strate-gie. Fährt ein Auto auf die Brücke, wird die Ampel für die Gegenrichtung automatisch auf rot geschaltet. Die Ressource „Brücke“ wird also erst dann freigegeben, wenn dies gefahrlos möglich ist, ohne einen Deadlock heraufzubeschwören.
Die dritte Strategie der Deadlock-Detection-and-Resolution versucht nicht, Deadlocks im Voraus zu verhindern, was in sehr dynamischen Anwendungsumgebungen auch normalerweise äußerst schwierig ist. Vielmehr sollen Deadlocks so bald wie möglich erkannt und anschließend behoben werden. Im Brückenbeispiel (Abbildung 5-3(c)) ent-spräche dies dem Vertrauen auf die Problemlösungskompetenz der Autofahrer. Ist eine Situation erreicht, in der sich zwei Autos gegenseitig blockieren, so muss einer der Fah-rer den Rückwärtsgang einlegen und die Brücke wieder freimachen.
5.1.3 Deadlocks in Containerterminals
Bei Fahrerlosen Transportsystemen in automatisierten Containerterminals können zwei Arten von Deadlocks auftreten: innerhalb des Fahrerlosen Transportsystems oder bei der Interaktion zwischen Fahrerlosem Transportsystem und anderen Geräten im Hafen, z.B. den Kränen.
Deadlocks innerhalb des Fahrerlosen Transportsystems
Die erste Art von Deadlocks betrifft hauptsächlich das Routing von AGVs. Deadlocks können zwischen zwei oder mehr Fahrzeugen entstehen, die sich gegenseitig im Fahr-kurs blockieren, weil sie z.B. ein Segment des FahrFahr-kurses aus unterschiedlichen Rich-tungen befahren, in dem sie einander nicht passieren können. Offensichtlich sind in die-sem Fall alle vier auf Seite 103 formulierten Bedingungen für einen Deadlock erfüllt:
zwei AGVs können für gewöhnlich ein Wegsegment nicht gleichzeitig benutzen („mutual exclusion“), ein AGV blockiert ein Wegsegment, solange es auf die Freigabe des nächsten Segments auf seiner Route wartet („wait for“), ein Segment wird erst dann freigegeben, wenn ein AGV es vollständig verlassen hat („no preemption“) und ein Zy-kel von aufeinander wartenden AGVs besteht („circular wait“). Wie man leicht sieht, sind die ersten drei Bedingungen immer erfüllt. Daher zielen im Bereich des Routings nahezu alle Ansätze zur Behandlung von Deadlocks auf Bedingung 4 ab.
Eine einfache Deadlock-Prevention-Strategie ist es, den Fahrkurs als einen einzigen unidirektionalen Kreis (Single-Loop) auszulegen. Dadurch wäre ein Zykel von aufein-ander wartenden AGVs praktisch verhindert (wenn man von dem unrealistischen Fall ausgeht, dass sich so viele Fahrzeuge auf dem Fahrkurs befinden, dass jedes sofort auf den Vorgänger auffährt). Die Fahrkurse der meisten Containerterminals besitzen in der Tat einen stark unidirektionalen Fahrkurs, der aus mehreren unidirektionalen Kreisen (multi-loop layout) besteht (siehe z.B. Abbildung 6-6 auf Seite 144). Werden allerdings komplexere Fahrkurse benötigt, müssen andere Deadlock-Handling-Techniken benutzt werden.
In der Literatur sind einige Verfahren zur Deadlock-Avoidance für Vehicle-Routing-Probleme vorgeschlagen worden. Moorthy et al. (2003) benutzen ebenso wie Yeh und Yeh (1998) eine Graphen-basierte Heuristik, um das Auftreten von Deadlocks vorher-zusagen. Gemäß dieser Ansätze muss ein Fahrzeug, das durch das Befahren eines Weg-segments einen Zykel aufeinander wartender Fahrzeuge schließen würde, solange warten, bis die sich die Situation geändert hat, oder es wird umgeleitet, so dass kein Deadlock auftreten kann. Wu und Zeng (2002) schlagen ein Petri-Net-basiertes Vorhen vor, um Deadlocks vorherzusagen und zu vermeiden. In Fanti (2002) werden ge-richtete Graphen verwendet, um die Zuweisung von Wegsegmenten zu Fahrzeugen und die Bewegungen der Fahrzeuge zu überwachen. Ebenfalls auf Graphenbasis arbeitet das von Kim et al. (2006) vorgeschlagene Verfahren, in dem Fahrzeuge mit Hilfe eines reservation graph ein oder mehrere Streckenabschnitte reservieren und freigeben.
Schließlich empfiehlt Reveliotis (2000) eine Modifikation des Banker’s algorithm, die ein robustes Verfahren zur Konfliktlösung zwischen AGVs darstellt. Während die ersteren Ansätze eindeutig zu den Deadlock-Avoidance-Strategien zu zählen sind, kann dieses letzte Verfahren auch als sehr flexibler Deadlock-Prevention-Ansatz betrachtet werden.
Verfahren zur Deadlock-Detection-and-Resolution für den Bereich des Vehicle-Rou-tings wurden in der Literatur bisher nicht vorgeschlagen. Offensichtlich sind einmal in Fahrkursen entstandene Deadlocks nur unter großem Aufwand wieder aufzulösen, da die Fahrzeuge ja schon physisch blockiert sind. Meist sind sehr schnell auch andere
Fahrzeuge indirekt von dem Deadlock betroffen. Im Beispiel der Brückenüberquerung aus Abbildung 5-3(c) auf Seite 104 könnte sich etwa hinter jedem der beiden Autos schon eine Schlange anderer Fahrzeuge angesammelt haben, die eine schnelle Auflö-sung des Deadlocks unmöglich macht.
Deadlocks innerhalb eines Fahrerlosen Transportsystems müssen durch entsprechende Routinen der Routing- und Verkehrsregelungsmodule vermieden werden. Diese Module werden in der Regel durch die AGV-Hersteller bereitgestellt und sind nicht Bestandteil dieser Arbeit. Im Folgenden wird diese Art von Deadlock daher nicht weiter berück-sichtigt.
Deadlocks zwischen Kränen und AGVs
Die zweite wichtige Kategorie von Deadlocks wird durch die Interaktionen des Fahrer-losen Transportsystems mit anderen Geräten hervorgerufen. Derartige Blockadeeffekte entstehen in Situationen, in denen Ressourcen sich gegenseitig zur Ausführung von Operationen bedürfen und aufeinander warten. Beobachtet wurde diese Art von Dead-locks bisher insbesondere in Flexiblen Fertigungssystemen (z.B. Kim und Kim, 1997 sowie Venkatesh und Smith, 2003). Sie können aber genauso gut in Containerterminals auftreten. Insbesondere AGVs sind anfällig für diese Art von Deadlocks, da sie immer noch eine zweite Ressource benötigen – entweder Containerbrücke oder Lagerkran – um eine Auf- oder Abladeoperation auszuführen. Da es an der Schnittstelle zwischen Fahrerlosem Transportsystem und den Kränen gewöhnlich keine Puffer gibt, sind die Auswirkungen von Deadlocks besonders schwerwiegend.
Erneut kann man leicht prüfen, dass alle vier der auf Seite 103 formulierten Bedingun-gen für einen Deadlock erfüllt sind: weder Kran noch AGV können mehr als eine Ope-ration gleichzeitig ausführen („mutual exclusion“), jede dieser Ressourcen ist blockiert (vgl. Abbildung 5-1 auf Seite 101), während sie auf eine andere Ressource zur Durchführung der Operation wartet („wait for“), eine Ressource wird erst nach Beendi-gung einer einmal begonnenen Operation freigegeben („no-preemption“), und ein Zykel aufeinander wartender Ressourcen kann entstehen wie in Abbildung 5-2(b) auf Seite 102.
Wie es scheint, gibt es trotz dieser vielfältigen Indizien für die Relevanz des Problems bisher keine Veröffentlichungen, die sich mit Deadlocks in Containerterminals befas-sen, welche durch die Interaktion zwischen dem Fahrerlosen Transportsystem und Krä-nen entstehen. Das mag daran liegen, dass dieses Problem praktisch nicht auftritt, wenn einfache Online-Regeln zur Steuerung von Fahrerlosen Transportsystemen im SLC-Modus verwendet werden, wie das bisher in Containerterminals praktiziert wird.
Aller-dings erfordern die in Kapitel 4 vorgeschlagenen komplexeren Verfahren für MLCs in jedem Fall die Auseinandersetzung mit dem Phänomen der Deadlocks.
Prinzipiell können alle drei Strategien – Deadlock-Prevention, Deadlock-Avoidance und Deadlock-Detection-and-Resolution – im Umgang mit Deadlocks benutzt werden.
Um allerdings die Strategie der Deadlock-Prevention effektiv einsetzen zu können, sind vollständige Information über alle künftigen Ereignisse und eine statische Anwendungs-umgebung notwendig. Weder das eine noch das andere trifft für Containerterminals zu.
Ähnlich sieht es bei der Strategie der Deadlock-Avoidance aus. Zwar ist diese prinzi-piell auch bei unvollständiger Information anwendbar, es wird jedoch in der Regel er-neut eine statische Anwendungsumgebung vorausgesetzt. Bei stochastischen Auf- und Abladezeiten, wie sie typischerweise in Containerterminals zu finden sind, stößt auch dieser Ansatz schnell an seine Grenzen.
Die dritte Variante – Deadlock-Detection-and-Resolution – ist hingegen nicht an derar-tige Beschränkungen gebunden. Nach Kim et al. (1997) ist dieser Ansatz außerdem derjenige, der die höchste Ressourcenauslastung des Systems gewährleistet. Allerdings müssen hier auch deutlich komplexere Prozeduren verwendet und in die Steuerungs-software des Terminals eingebunden werden. Dadurch ist der logistische Aufwand für das Deadlock-Handling bedeutend höher.
Kim et al. (1997) betrachten Deadlock-Prevention (in dem Artikel mit „prevent dead-lock without look-ahead” bezeichnet) als den konservativsten Ansatz, gefolgt von Deadlock-Avoidance (im Artikel „prevent deadlock with look-ahead“) und schließlich Deadlock-Detection-and-Resolution (bzw. „recovery“) als flexibelstem Ansatz. Aus den oben genannten Gründen wird im Folgenden ein Ansatz zur Deadlock-Detection-and-Resolution entwickelt.