3.1.7 Korrektheit von Objekten

1. 3.1.7 Korrektheit von Objekten Voraussetzung für die Diskussion der Korrektheit von nichtsequentiell benutzten abstrakten Objekten: Modellbasierte Spezifikation: Z = abstrakte Zustandsmenge eines Objekts { P } op(...) { Q } = auf Z bezogene Spezifikation, für jede Operation op Voraussetzung Effekt (precondition) (postcondition)

2. Szenario: Abläufe, an denen ein Objekt sowie mehrere nebenläufige Prozesse beteiligt sind, deren Aktionen Ausführungen von Operationen auf dem Objekt sind. Das Ergebnis eines Ablaufs besteht aus - dem abstrakten Endzustand des Objekts - und den Folgen der Aufrufergebnisse für die beteiligten Prozesse.

3. Beispiel mit 2 Prozessen: P: s.push('1'); x = s.pop(); Q: s.push('a'); s.push('b'); y = s.pop(); Mögliche Abläufe mit möglichem Ergebnis:  P:push pop x == 'a' Q:push push pop y == 'b' s == "1"  P:push pop x == '1' Q:push push pop y == 'b' s == ""

4. Ein Ablauf ohne Überlappungen von Aktionen heißt seriell. Mögliche serielle Abläufe mit Ergebnis:  P:push pop x == 'a' Q:push push pop y == 'b' s == "1" P:push pop x == '1' Q:push push pop y == 'b' s == "a"

5. Def. 1: Zwei Abläufe heißen äquivalent, wenn ihre Ergebnisse gleich sind. Beispiel: Von den Abläufen  sind nur  und  äquivalent. Def. 2: Ein Objekt heißt serialisierbar, wenn es zu jedem möglichen Ablauf A einen äquivalenten seriellen Ablauf („Serialisierung von A“) gibt. Beispiel: Zu  gibt es den äquivalenten seriellen Ablauf . Zu  gibt es aber keinen – also ist das Objekt nichtserialisierbar.

6. Standard-Forderung für Korrektheit in nichtsequentiellen Umgebungen: (seq.) Korrektheit + Serialisierbarkeit Bemerkungen: Monitore (der bisher betrachteten Art) sind serialisierbar (weil es a priori nur serielle Abläufe gibt). Serialisierbarkeit kann u.U. auch mit schwächerer Synchronisation erreicht werden (3.1.6).

7. Außerdem:Mitunter verzichtet man auf die Serialisierbarkeit, d.h. man läßt zu, daß ein Ablauf mit Überlappungen ein Ergebnis haben kann, das durch keine Serialisierung des Ablaufs erzielt werden kann. Konsequenz: Spezifikation muß explizit die zusätzlichen Effekte angeben (und eingrenzen!), die bei Überlappungen auftreten können.

8. Beispiel: interface SortedSet { // s :: Set // initially empty boolean add(Object x); // pre: - // post: s == union 's {x} boolean replace(Object old, Object new); // pre: contains s old // post: s == union(diff 's {old}) {new} void iterate(Operation op); // pre: all(\x->pre op x)s // post: all(\x->post op x)s && s=='s }

9. 1. Realisierung als Monitor wäre zu restriktiv – angesichts des u.U. langwierigeniterate ! 2. Dennoch Serialisierbarkeit zu fordern könnte die Implementierung sehr schwierig machen (?). 3. Es könnte für die Anwendung akzeptabel sein, daß ein Ersetzen (replace(old,new)) während einer Traversierung (iterate) dazu führen könnte, daß die Traversierung sowohloldals auchnewberührt – oder auch keines von beiden. Beispiel: Ausdrucken einer aktuellen Teilnehmerliste, an der laufend Veränderungen durchgeführt werden. 4. Die Spezifikation muß entsprechend erweitert werden.