Für die weitere Betrachtung des Transaktionsprinzips, das wir im zweiten Teil der Vorlesung kennengelernt

haben, möchte ich noch mal auf diese Kassoperation zu sprechen kommen.

Und zwar, wenn man eine prozedurale Abstraktion dieses Befehls vornimmt, da sollte man sich

dann immer im Klaren darüber sein, was denn eigentlich der Mehraufwand ist, der dann einfach

aufgrund von Prozedurkonzepten hinzukommt.

Man sieht es ein bisschen hier, wo man dann tatsächlich diese Kassoperation wirklich

als normale C-Prozedur oder C-Funktion hat, aber die eigentlichen Operationen hier selbst

des Kasses sich praktisch nur auf die Zeilen 6, 7 und 8 beschränken.

Das andere dazu, was wir haben, also hier ein Register retten, hier unten wieder Register

herstellen und hier im Wesentlichen dann auf die Argumente der Prozedur Kass entsprechend

zuzugreifen, also die Werte hier vom Stack dann letztendlich lesen und in die entsprechenden

Register transportieren, damit man denn innerhalb der Prozedur mit den Werten dann arbeiten

kann, sind schon großer Mehraufwand im Vergleich zu dem eigentlichen funktionalen Anteil, den

man jetzt hier mit dem Kass dann eigentlich verbindet.

Das heißt, diese Unkosten im Vergleich zu den intrinsischen Funktionen, die der Compiler

halt hat, sind schon beträchtlich und deshalb sollte man halt eher diese intrinsischen

Funktionen des Compilers auch wirklich nutzen, damit da dann halt eben eine entsprechend

optimierte Code herauskommt und der Overhead letztendlich nicht zu groß ist.

Man muss einfach diesen Code, den wir hier haben auf der Folie 37, einmal vergleichen

mit dem Code, wo denn die Inline-Variante von diesem Compay Exchange denn verwendet

worden ist, wo doch drei Befehle versus diese zwölf Befehle, die wir halt hier denn eigentlich

in Kauf nehmen müssen für die Durchführung einer solchen Kassoperation gegenüberzustellen

sind und damit der Mehraufwand denn durchaus deutlich wird.

Aber ein anderer Punkt ist eigentlich für die Kassoperation wichtig, denn es ist eine

bestimmte Untiefe, so eine Sache, die halt als ABA-Problem oder ABAP-Problem bezeichnet

wird, die so typisch ist für so eine Operation wie diesen Kass.

Dahinter steckt eine falsch-positive Aussage, die man halt oder eine Annahme, die man letztendlich

trifft, ein sogenanntes false-positive bei der Ausführung oder bei der Ergebnisauswertung

genau genommen von so einer Kassoperation bezogen auf den Inhalt einer bestimmten Variable,

die in einer bestimmten Adresse denn halt steht.

Denn wenn das Kass erfolgreich ausgeführt wird, dann gehen wir erstmal davon aus, dass

die Transaktion ja offensichtlich gelungen ist.

Das heißt, die Kassoperation ist insofern gelungen, dass die Wertzuweisung stattgefunden

hat, aber da diese Kassoperation in eine Transaktion in so einem größeren umfassenden Kontext eingebettet

ist, muss man sich schon die Frage stellen, ob denn damit tatsächlich auch die Transaktion

als gelungen wirklich gilt.

Und das ist durchaus ein Problem, denn man weiß eben eigentlich nur, dass die Vergleichen

mit Operanten identisch sind und damit assoziiert man denn eigentlich mit dieser Gleichheit

durchaus eine bestimmte Bedingung bezüglich eines globalen Zustands.

Das ist sozusagen die positive Sicht, die man hat.

Es kann aber sein, dass genau diese Behauptung, die man jetzt hier aufstellt oder diese Annahme,

die man hier trifft, in dem Moment, wo man denn wirklich das Kass durchführt, man kommt

praktisch aus diesem Kassbefehl zurück, nicht mehr stimmt, faktisch nicht mehr stimmt.

Das sind Faults.

Dazu müssen wir uns mal ein Beispiel angucken.

Nehmen wir mal an, wir haben hier zwei Prozesse P1 und P2, die verwenden also gleichzeitig

einen Wert, der an der Adresse li denn letztendlich steht.

Und das soll jetzt so sein, dass ein Wert a gelesen wird von dem Prozess P1 aus dieser

Speicherstelle I und Prozess P1 nimmt damit einen bestimmten globalen Zustand halt an,

den wir es eins bezeichnen würden.