• Keine Ergebnisse gefunden

Kapitel 6 Eine Agentenarchitektur für Dienste 154

6.6 Scheduler

Prinzipiell kann jedes Handlungsskript quasi-parallel in einem eigenen Thread ab-laufen. Einschränkungen ergeben sich nur, wenn logische Abhängigkeiten zwi-schen den Skripten bestehen, die eine Parallelität verbieten - diese Situationen kön-nen bei der Beschreibung der agentenspezifischen Fähigkeiten deklariert werden, (siehe Abschnitt 5.5.3). Andererseits ist es aus Effizienzgründen wenig sinnvoll, zu viele Skripte parallel zu starten, weil damit die Performance durch den hohen Auf-wand des Thread-Handlings abfällt.

Aus diesen Gründen findet zwischen der Handlungsplanung des Intentionalitäts-moduls und der Handlungdurchführung des Skriptmanagers ein Scheduling statt.

Der Scheduler verwaltet die zur Ausführung freigegebenen Skriptinstanzen in einer Liste und ordnet ihnen Prioritäten zu. Er leitet die am höchsten priorisierten Instan-zen dem Skriptmanager zur Abarbeitung zu und berücksichtigt dabei die festgelegte Obergrenze ausführbarer Skripte10.

Weil die Aktivierung und Deaktivierung von Handlungen im Intentionalitätsmo-dul dynamisch erfolgt, wird die ScheIntentionalitätsmo-dulingfunktionalität entsprechend häufig benö-tigt. Bei der Konzeption des Schedulingverfahrens standen daher Effizienz und in-krementelles Arbeiten im Vordergrund.

6.6.1 Priorisierung von Skripten

Jedem Skript wird initial eine Prioritätsstufe zugeordnet, die von der Aktivierungs-ursache abhängt. Daneben finden zur Laufzeit Neuberechnungen statt, wenn weite-re Begründungen vorliegen oder Unterbweite-rechungen stattgefunden haben. Die Priori-tätsskala reicht von 0 bis 10, wobei 10 die höchste Priorität ausdrückt.

• Stufe 10 - Skriptkreierung durch sensing-alarm. Um die Reaktivität zu gewähr-leisten, werden sensing-alarms mit der höchsten Priorität behandelt.

9. Bei Verwendung von Sprechakten oder aufgrund zeitlicher Zusagen für andere Agenten.

10. Die Zahl maximal parallel laufender Handlungsskripte kann dynamisch über die Agentenoberfläche ein-gestellt werden (siehe Abschnitt 5.7.4).

• Stufe 9 - Unterbrochene Skripte. Ein Skript, das bereits in Ausführung war, dann aber unterbrochen wurde, wird bei der Reaktivierung fokussiert weiterverfolgt.

Damit ist sichergestellt, daß auch niedrig priorisierte Handlungen, sofern sie einmal gestartet wurden, zum Abschluß gebracht werden.

• Stufe 8 - Skript - Subskriptbeziehungen. Wenn ein Skript ein anderes aufruft, dann bekommt das Subskript eine hohe Priorität. Dies ist deshalb sinnvoll, weil das Subskript nicht direkt aus dem Skript ausgeführt, sondern über den Schedu-ler aktiviert wird. Damit ist ein ähnlicher Fall wie bei unterbrochenen Skripten gegeben. Das „Mutterskript“ behält seine ursprüngliche Priorität.

• Stufen 7 bis 1 - durch Sprechakte und Ziele aktivierte Skripte. Im Falle eines Sprechakts beträgt der Defaultwert 3. Bei Zielen werden deren Prioritäten, wel-che vom Benutzer bei der Definition angegeben wurden, übernommen. Inner-halb des Bereichs von 1 bis 7 können Prioritäten durch das Intentionalitätsmodul geändert werden.

Jedes vom Interpreter zur Verarbeitung freigegebene Skript wird zunächst anhand der Begründung priorisiert. Wenn ein Skript durch eine neue Unterstützung ver-stärkt oder durch eine weggefallene Begründung abgeschwächt wird, findet eine Neupriorisierung statt. Die neue Priorität berechnet sich nach der Anzahl der Unter-stützungen i und der höchsten statischen Priorität der Reasons ge-mäß der folgenden Formeln:

Ein Skript trägt also die Priorität seines stärksten Reasons plus eins für jede weitere Begründung. Zusätzlich wird sichergestellt, daß der Bereich von 0 bis 7 nicht über-oder unterschritten wird.

6.6.2 Aktivitätenmanagement

Interpreter und Skriptmanager tragen zu schedulende Aktivitäten in eine Agenda des Schedulers ein. Vom Interpreter kommen Informationen über zu startende und abzubrechende Skripte herein, während der Skriptmanager Benachrichtigungen zu beendeten, unterbrochenen oder abgebrochenen Handlungen sendet. Durch Verar-beitung der Agendaeinträge aktualisiert der Scheduler eine Datenstruktur, in der alle aktiven Skripte mit ihren Verarbeitungszuständen und Prioritäten enthalten sind. In seiner Rolle als Kontrollinstanz des Skriptmanagers verfolgt der Scheduler zwei Strategien: Zum einen maximiert er die Auslastung in bezug auf parallel laufende Skripte, zum anderen werden in Ausführung befindliche Skripte möglichst nicht

un-PR

terbrochen. Ein Pünktlichkeit berücksichtigendes Zeitmanagement findet hingegen nicht statt.

Vor dem Start eines Skripts wird dessen Inkompatibilitätsliste (siehe Abschnitt 5.5.3 auf Seite 138) betrachtet. Es darf nur dann gestartet werden, wenn keines der in der Liste enthaltenen Skripte gerade in Ausführung oder unterbrochen ist. Solan-ge die Obergrenze für parallel laufende Skripte nicht erreicht ist, leitet der Scheduler ausführbare Skriptinstanzen, nachdem er sie priorisiert und als „laufend“ vermerkt hat, an das ausführende Modul weiter. Wenn die Kapazität des Skriptmanagers aus-gelastet ist, werden Skripte mit dem Vermerk „nicht laufend“ gescheduled. Eine Ausnahme bilden die sensing-alarms: Um dem Reaktivitätsanspruch zu genügen, werden die mit ihnen assoziierten Skripte sofort ausgeführt. Sollte im Skriptmana-ger kein Platz für ein weiteres Skript vorhanden sein, so wird dieser geschaffen, in-dem das am geringsten priorisierte Skript unterbrochen wird. Dieses wird als „nicht laufend“ vermerkt und bekommt die Priorität 8 zugewiesen, womit es einen vorde-ren Platz in der Warteliste auszufühvorde-render Skripte einnimmt.

Ein in der Warteschlange ruhendes Skript wird erst dann dem Skriptmanager zu-geführt, wenn dort ein Platz frei wird und außerdem keine höher priorisierten Skrip-te auf Ausführung warSkrip-ten. SkripSkrip-te, die niedrig eingestuft sind, haben also in Lastsi-tuationen nur geringe Chancen auf Aktivierung, können aber durch Mehrfachakti-vierungen in der Warteschlange nach vorne rücken.

TABELLE 8. verarbeitbare Nachrichten des Schedulers Ursprung Inhalt Verarbeitung

Interpreter schedule Skript

Eintrag der Skriptinstanz in die Prioritätenliste;

wenn sensing-alarm: SensingAlarm ausführen, sonst: wenn Anzahl laufender Skripte < Obergrenze: Skriptinstanz dem Skriptmanager zur Ausführung übergeben

beende Skript

Skripteintrag aus Schedule entfernen;

wenn Skript laufend oder unterbrochen, dann Beendigung des Skripts beim Skriptmanager veranlassen

verstärke Skript

erhöhe Priorität unter Berücksichtigung des neuen Reasons schwäche

Skript ab

vermindere Priorität unter Berücksichtigung des weggefal-lenen Reasons