nsp3.1.7

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
(precondition)
Effekt
(postcondition)
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.
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:
Q:
push
push
pop
push
x == 'a'
pop
y == 'b'
s == "1"

P:
Q:
push
push
pop
push
x == '1'
pop
y == 'b'
s == ""
Ein Ablauf ohne Überlappungen von Aktionen heißt seriell.
Mögliche serielle Abläufe mit Ergebnis:

P:
push
pop
push
Q:
x == 'a'
push pop
y == 'b'
s == "1"

push pop
P:
Q:
push
x == '1'
push pop
y == 'b'
s == "a"
Def. 1:
Zwei Abläufe heißen äquivalent,
wenn ihre Ergebnisse gleich sind.
Beispiel:
Def. 2:
Von den Abläufen  sind nur
 und  äquivalent.
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 nicht serialisierbar.
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).
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.
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
1. Realisierung als Monitor wäre zu restriktiv –
angesichts des u.U. langwierigen iterate !
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 sowohl old als auch new berü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.