So, die Transaktion als Alternative zur Umlaufsperre. Wir werden sehen, dass bei

diesen transaktionalen Algorithmen wir eben auch kreiseln, nur mit Nutzarbeit. So kann man das

mal kurz formulieren. Ich werde kurz auf die Motivation und das Prinzip dieser Form der

transaktionalen Programmierung eingehen und dann schauen wir uns danach noch ein paar Beispiele,

einfache Beispiele an und diskutieren mal diesen Lösungsansatz. Nun, was sind denn nun die

Nachteile der blockierenden Synchronisation? Und zwar allgemein sei es nun Monitore, Simafor oder

diese Umlaufsperren, die wir jetzt hier gerade heute kennengelernt haben, bezieht sich einmal

auf die Leistung der parallelen Systeme. Allgemein, die bricht nämlich durchaus ein. Man reduziert

Busbandbreite, wenn man insbesondere mit diesen Spinlocks arbeitet und generell für alle diese

Form von blockierenden Synchronation erhöht man ja den Anteil der sequenziellen Programmbereiche.

Das heißt, man grenzt Parallelität letztendlich ein. Das ist ein so ein Aspekt, die man

berücksichtigen muss. Es ist nicht zwingend, dass deshalb die Performance einbricht, aber es kann eben

der Fall sein. Denn ein ganz wichtiger Punkt ist die Robustheit. So ein kritischer Abschnitt,

egal mit Monitore Simafor oder Simafor, ist ein sogenannter Single Point of Failure. Nun, wenn

der Prozess, der sich gerade im kritischen Abschnitt befindet, abstürzt, dann lässt er

diesen gesperrt zurück. Und die weitere Konsequenz kann dann durchaus die sein, dass das gesamte

System entlanggelegt ist. Kein anderer Prozess wird mehr über diesen kritischen Abschnitt

übergehen. Und es ist alles andere als einfach, einfach zu sagen, dass wenn ein Prozess im kritischen

Abschnitt abgestürzt ist, man kann sich dann merken, dass sich Prozesse gerade in solchen

Abschnitten befinden, dass man den dann einfach vom System aus freigibt. Man muss einfach beachten,

wozu der kritische Abschnitt da ist. Da soll am Ende eine konsistente Berechnung durchgeführt

worden sein. Ein konsistenter Systemzustand muss existieren und man weiß überhaupt gar nicht,

wie weit die Inkonsistenz dieses Zustands noch gegeben ist. Deshalb geht man normalerweise nicht

hin und gibt den einfachen kritischen Abschnitt frei, wenn man festgestellt hat, dass ein Prozess

da drin abgestürzt ist. Also das ist ein Problem, was man generell mit solchen blockierenden

Verfahren denn hat. Und dann die Interferenz mit dem Planer. Man sequenzialisiert hier die Prozesse

an den kritischen Abschnitt. Wir haben gesehen, mit dem Ticket Spinlock, dann kann man da so ein

faires Verfahren wählen. Das ist aber eine FIFO-Variante. Jeder Back-off-Mechanismus, die Wartezeiten,

die man da hat, die generieren FIFO-Reihenfolgen, wenn man es genau nimmt. Und die müssen nun

überhaupt nicht dazu passen, wie der Planer sozusagen meint, die Ressource CPU zu vergeben,

indem ein Prozess in den kritischen Abschnitt eintritt. Es ist ja auch darüber eine Entscheidung

getroffen, dass dieser Prozess jetzt diese CPU nutzen darf, um diesen kritischen Abschnitt

dann letztendlich zu laufen. Und diese Entscheidung findet normalerweise auf der Planung, auf der

Scaddling-Ebene statt. Und die würde dann halt durch blockierende, durch faire blockierende

Verfahren durchaus beeinträchtigt werden. Das kann dann zu sowas wie Prioritätsverletzungen

führen oder Prioritätsumkehr-Probleme, die durchaus schwerwiegend sind, insbesondere

für echtzeitabhängige Prozesse. Man soll mal nach dem Mars Passpoint da googeln und

dann wird man durchaus nette Beschreibungen zu dieser Problematik der Prioritätsumkehr

finden. Und dann halt die Frage der Lebendigkeit. Einige oder möglicherweise mehrere Prozesse.

Wir haben schon gesehen, dass man Starvation-Problemen hat. Also Prozesse könnten verhungern, je nachdem,

wie dieser Schlossalgorithmus eben aussieht. Das gilt aber generell auch für Verfahren

der Semaphore oder des Monitors selbst. Oder ja, noch viel schlimmer, dass man Verklemmungen

bekommt, dass man Deadlocks im System hat und letztendlich das zum Stillstand von Prozessen

dann halt wirklich führt. Also nicht nur einfach zur Verhungerung, wo man ja dann eigentlich

immer noch eine gewisse Wahrscheinlichkeit sieht, dass der Prozess weitermachen kann.

Beim Deadlock ist garantiert, dass die Prozesse, eine gewisse Menge von Prozessen einfach miteinander

verklemmt sind und keine sinnvolle Arbeit mehr durchführen, egal ob sie mit Umlaufsperren,

Semaphore oder Monitore halt in die Blockierung geführt worden sind. Ein anderer Aspekt

ist, so einen wechselseitigen Ausschluss auf der Artware-Ebene zu haben, in Form von Spezialbefehlen,

die wir schon kennengelernt haben, nämlich dieses Test in ZCAS und FAA. Da hat die Hardware