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)

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: push pop x == 'a'

Q: push push pop y == 'b'

s == "1"

P: push pop x == '1'

Q: push push pop y == 'b'

s == ""

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"

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 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 mitschwä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.