Synchronisation in Aktorsystemen

Dieses Papier präsentiert einen Mechanismus zur Schlichtung paralleler Anfragen an gemeinsame Ressourcen. Dieser Mechanismus ist der Serializer, der als eine Art Schutzmechanismus beschrieben werden kann, da er unangemessene Zugriffsreihenfolgen auf eine geschützte Ressource verhindert. Der Mechanismus ist eine Verallgemeinerung und Verbesserung des Monitormechanismus von Brinch-Hansen und Hoare. Serializer versuchen, wünschenswerte strukturelle Merkmale der Synchronisationssteuerung in ein kohärentes Sprachkonstrukt zu systematisieren und zu abstrahieren. Sie stellen eine Verbesserung der Modularität der Synchronisation im Vergleich zu Monitoren in mehreren Aspekten dar. Monitore synchronisieren Anfragen, indem sie ein Paar von Operationen für jeden Anfragetyp bereitstellen; Beispiele sind STARTREAD/ENDREAD und STARTWRITE/ENDWRITE für die Leser-Schreiber-Problematik. Ein solches Paar von Operationen muss in einer bestimmten Reihenfolge verwendet werden, damit die Synchronisation ordnungsgemäß funktioniert, jedoch wird durch nichts im Monitorkonstrukt diese Verwendung erzwungen. Serializer integrieren diesen strukturellen Aspekt der Synchronisation in einen einheitlichen Mechanismus, um eine ordnungsgemäße Anmeldung und Abmeldung zu gewährleisten. Bei der Planung des Zugriffs auf eine geschützte Ressource ist es oft gewünscht, in einer Warteschlange auf eine bestimmte Bedingung zu warten, bevor die Ausführung fortgesetzt wird. Monitore verlangen, dass ein Prozess, der in einer Warteschlange wartet, für immer inaktiv bleibt, es sei denn, ein anderer Prozess signalisiert dem inaktiven Prozess ausdrücklich, dass er fortfahren soll. Serializer verbessern die Modularität der Synchronisation, indem sie festlegen, dass die Bedingung für die Wiederaufnahme der Ausführung ausdrücklich angegeben werden muss, wenn ein Prozess in eine Warteschlange eintritt, wodurch es unnötig wird, dass Prozesse andere Prozesse signalisieren. Jeder Prozess bestimmt selbst die Bedingungen, die für seine weitere Ausführung erforderlich sind. Das Verhalten eines Serializers wird unter Verwendung des Aktor-Nachrichtenaustauschmodells definiert. Verschiedene Versionen der "Leser-Schreiber"-Problematik werden verwendet, um zu veranschaulichen, wie die Struktur eines Serializers auf natürliche Weise mit der Struktur des zu lösenden Schlichtungsproblems übereinstimmt. Diese Übereinstimmung erleichtert es, einen Scheduler aus Verhaltensspezifikationen zu synthetisieren und zu überprüfen, ob eine Implementierung ihre Spezifikationen erfüllt. Es wird kein Anspruch auf die "Vollständigkeit" des Serializer-Mechanismus erhoben, abgesehen davon, dass gezeigt wird, dass Semaphoren mit Hilfe von Serializern implementiert werden können. Darüber hinaus wird keine "vollständige" Lösung für die "Kein-Hungern"-Spezifikation vorgeschlagen, die erfordert, dass eine Ressource auf jede Anfrage antwortet, die sie erhält. Vielmehr wird an einigen einfachen Beispielen gezeigt, dass Serializer einen Schritt in Richtung einer besseren Strukturierung des parallelen Zugriffs auf gemeinsame Ressourcen darstellen und dass Beweise dafür, dass Hunger für diese Beispiele unmöglich ist, mit Serializern einfacher sind als mit einigen der derzeit existierenden Mechanismen zur Steuerung des parallelen Zugriffs auf Ressourcen.