15.3 On-Request-Invalidierung
15.3.2 Dynamische Page-Owner-Zuordnung
Bei einer Noforce-Ausschreibstrategie, die der Force-Alternative vorzuziehen ist, stellt sich wiederum die Frage der Update-Propagierung. Wie schon in Kap. 15.2.2 diskutiert, läßt sich bei dynamischer Page-Owner-Zuordnung die Page-Owner-Lokalisierung einfach und ohne zusätzliche Kommunikation in das Sperrprotokoll integrieren, indem der Page-Owner ebenfalls in der globalen Sperrtabelle geführt wird. Der GLM kann damit bei der Sperrgewährung den zuständigen Page-Owner mitteilen, von dem dann die aktuelle Version der Seite angefordert wird. Eine solche Seitenanforderung wird nur notwendig, wenn ein Page-Owner in der globalen Sperrtabelle vermerkt ist (d.h., die Seitenversion auf Platte nicht aktuell ist) und eine invalidierte oder keine Version der Seite im anfordernden Rechner gepuffert ist.
Die Seitenanforderung an den Page-Owner ist analog zum Lesen der Seite von Platte, kann jedoch bei direktem Seitentransfer deutlich schneller abgewickelt werden. Dennoch ist die zweifache Verzögerung der Transaktion zur Sperranforderung und der Seitenanforderung unbefriedigend, zumal damit i.d.R. 4 Nachrichten verbunden sind. Eine leichte Verbesserung wird erreicht, wenn der GLM die Seitenanforderung für die Transaktion an den Page-Owner weitergibt, da somit eine frühere Übertragung der Seite veranlaßt werden kann. Eine weitergehende Verbesserung wird bei fester Page-Owner-Zuordnung möglich (s.u.).
Die Änderung einer Seite in verschiedenen Rechnern bedingt bei dynamischer Page-Owner-Zuordnung eine Migration der Page-Owner-Funktion. Dies verlangt nicht nur Anpassungen in der globalen Sperrtabelle, sondern auch in den Verarbeitungsrechnern, da sie wissen müssen, für welche Seiten sie die Page-Owner-Funktion besitzen. Somit wird auch der explizite Entzug der Page-Owner-Funktion notwendig, bevor ein neuer Rechner als Page-Owner auftreten kann. Die Migration der Page-Owner-Funktion läßt sich vielfach mit dem Seitentransfer vom alten zum neuen Page-Owner kombinieren, so daß zusätzliche Verzögerungen weitgehend vermieden werden. Bei einem Austausch geänderter Seiten über Externspeicher wird die Page-Owner-Funktion mit dem Ausschreiben ohnehin hinfällig; erfolgt danach eine Änderung in einem anderen Rechner, wird dieser zum neuen Page-Owner. Beim direkten Austausch geänderter Seiten kann damit auch ein expliziter Transfer der Page-Owner-Funktion erfolgen. Da der Seitentransfer mit der Sperrgewährung verknüpft ist, sollte in der globalen Sperrtabelle in diesem Fall ein Rechner bereits bei der Gewährung einer Schreibsperre als Page-Owner eingetragen werden. Bei erstmaliger Änderung einer Seite im System genügt die Anpassung der Page-Owner-Angabe bei Freigabe der Schreibsperre.
Beispiel 15-3
- Abb. 15-7 verdeutlicht die Funktionsweise der dynamischen Page-Owner-Zuordnung für das Beispiel aus Abb. 15-6, wobei eine On-Request-Invalidierung über Invalidierungsvektoren sowie ein direkter Austausch geänderter Seiten unterstellt ist. Der Page-Owner-Eintrag (PO) in der globalen Sperrtabelle ist für die ungeänderte Seite B zunächst unbelegt und wird für die erste Änderung bei der Freigabe der Schreibsperre auf R3 gesetzt. Bei der nachfolgenden Anforderung einer Schreibsperre durch R1 erkennt der GLM die Pufferinvalidierung aufgrund des gesetzten Invalidierungsbits. Da R3 als Page-Owner geführt ist, stellt der GLM direkt die Seitenanforderung an ihn (Nachricht 2); zugleich wird die Aufgabe der Page-Owner-Funktion verlangt, da in R1 eine Änderung der Seite beabsichtigt ist. Rechner R3 übeträgt daraufhin die Seite an R1 und signalisiert gleichzeitig die Aufgabe der Page-Owner-Funktion an den GLM. Der GLM trägt R1 als neuen Page-Owner ein und teilt dies R1 mit der Gewährung der Schreibsperre mit (Nachricht 4). Damit konnte die Page-Owner-Migration vollkommen mit dem Seitentransfer und der Sperrgewährung kombiniert werden.
Abb. 15-7: On-Request-Invalidierung mit dynamischer Page-Owner-Zuordnung
