2025-11-17T23:28:19.912332

Verifying Correctness of Shared Channels in a Cooperatively Scheduled Process-Oriented Language

Pedersen, Chalmers
Correct concurrent behaviour is important in understanding how components will act within certain conditions. In this work. we analyse the behaviour of shared communicating channels within a coorporatively scheduled runtime. We use the refinement checking and modelling tool FDR to develop both specifications of how such shared channels should behave and models of the implementations of these channels in the cooperatively scheduled language ProcessJ. Our results demonstrate that although we can certainly implement the correct behaviour of such channels, the outcome is dependant on having adequate resources available to execute all processes involved. We conclude that modelling the runtime environment of concurrent components is necessary to ensure components behave as specified in the real world.
academic

Überprüfung der Korrektheit gemeinsamer Kanäle in einer kooperativ geplanten prozessorientierten Sprache

Grundlegende Informationen

  • Papier-ID: 2510.11751
  • Titel: Verifying Correctness of Shared Channels in a Cooperatively Scheduled Process-Oriented Language
  • Autoren: Jan Pedersen (University of Nevada Las Vegas), Kevin Chalmers (Ravensbourne University)
  • Klassifizierung: cs.PL (Programmiersprachen)
  • Veröffentlichungsdatum: 12. Oktober 2025 (arXiv-Preprint)
  • Papier-Link: https://arxiv.org/abs/2510.11751

Zusammenfassung

Dieses Papier analysiert das Verhalten gemeinsamer Kommunikationskanäle in kooperativ geplanten Laufzeitumgebungen. Die Forschung nutzt das formale Verifikationswerkzeug FDR zur Entwicklung von Spezifikationen für gemeinsame Kanalverhalten und Modellen der Kanalimplementierung in der Sprache ProcessJ. Die Ergebnisse zeigen, dass zwar korrektes Kanalverhalten implementiert werden kann, die Ergebnisse jedoch von ausreichenden Ressourcen zur Ausführung aller relevanten Prozesse abhängen. Die Forschung kommt zu dem Ergebnis, dass die Modellierung der Laufzeitumgebung von nebenläufigen Komponenten notwendig ist, um sicherzustellen, dass Komponenten in der realen Welt gemäß Spezifikation verhalten.

Forschungshintergrund und Motivation

Problemhintergrund

  1. Bedeutung der Korrektheit nebenläufiger Software: Das korrekte Verhalten nebenläufiger Systeme ist entscheidend für das Verständnis, wie Komponenten unter bestimmten Bedingungen ausgeführt werden. Traditionelle Testmethoden werden zwar häufig verwendet, können aber möglicherweise nicht alle potenziellen Nebenläufigkeitsfehler aufdecken.
  2. Notwendigkeit formaler Verifikation: Die Autoren illustrieren mit dem Beispiel von Mars-Rover-Software, dass ein einfacher Deadlock-Fehler möglicherweise 8 Millionen Sekunden (über 90 Tage) warten muss, um mit 50%iger Wahrscheinlichkeit durch Tests entdeckt zu werden, während formale Verifikation mit CSP und FDR solche Fehler sofort aufdecken kann.
  3. Herausforderungen bei der Verifikation von Laufzeitsystemen: Da viele Programme auf Laufzeitsystemen von Programmiersprachen aufgebaut sind, wird es entscheidend, sicherzustellen, dass Laufzeitsysteme fehlerfrei sind und sich gemäß Spezifikation verhalten.

Einschränkungen bestehender Methoden

  1. Ignorieren der Ausführungsumgebung: Traditionelle auf Kanalsystemen basierende Verifikationsmethoden modellieren nicht das Laufzeitsystem, Ausführungssystem, Hardware usw. und gehen davon aus, dass bereite Ereignisse verfügbar bleiben, bis sie geplant werden.
  2. Annahme von Ressourcenüberfluss: Standardmodellierungsmethoden gehen davon aus, dass Ereignisse sofort auftreten können, was bedeutet, dass Ressourcen bei der Ausführung eines Ereignisses verfügbar sind. Diese extreme Annahme trifft in der Realität jedoch nicht zu.
  3. Auswirkungen der Planungsumgebung: Prozesse müssen am Ende der Warteschlange warten, um geplant zu werden, und ihre Ereignisse sind nicht sofort verfügbar. Traditionelle Methoden berücksichtigen dies jedoch nicht.

Forschungsmotivation

ProcessJ ist eine prozessorientierte Programmiersprache mit CSP-Semantik, die kooperative Planung nutzt und auf der JVM läuft. Dieses Papier zielt darauf ab, die Korrektheit der Implementierung gemeinsamer Kanäle in der ProcessJ-Laufzeit zu überprüfen, mit besonderem Fokus auf die Auswirkungen der Planungsumgebung auf das Kanalverhalten.

Kernbeiträge

  1. Überprüfung der Korrektheit der ProcessJ-Implementierung gemeinsamer Kanäle: Nachweis, dass die ProcessJ-Implementierung gemeinsamer Kanäle mit dem vorhandenen kooperativen Planer korrekt ist, durch CSP-Übersetzung und Verfeinerungsprüfung mit einem universellen Modell gemeinsamer Kanäle.
  2. Entwicklung eines erweiterten algebraischen Beweises für die Spezifikation gemeinsamer Kanäle: Bereitstellung eines formalen Beweises, dass die Spezifikation gemeinsamer Kanäle sich tatsächlich als CSP-Kanäle verhält.
  3. Weiterer Nachweis der Beziehung zwischen Ressourcen und aktiven Prozessen: Erneute Demonstration der Beziehung zwischen verfügbaren Ressourcen und der Anzahl aktiver Prozesse zur Erfüllung der Spezifikation. Der Nachweis zeigt, dass die Anzahl der verfügbaren Planer gleich oder größer als die Anzahl der Prozesse im System sein muss, um Verfeinerung in beide Richtungen zwischen Spezifikation und Modell zu erreichen.

Methodische Details

Aufgabendefinition

Die Kernaufgabe dieses Papiers ist die Überprüfung der Korrektheit der Implementierung gemeinsamer Kanäle in der Sprache ProcessJ. Dies umfasst speziell:

  • Eingabe: Java-Implementierungscode gemeinsamer ProcessJ-Kanäle und CSP-Spezifikation
  • Ausgabe: Verifikationsergebnisse, die nachweisen, ob die Implementierung der Spezifikation entspricht
  • Einschränkungen: Berücksichtigung von Ressourcenbeschränkungen in der kooperativ geplanten Umgebung

Modellarchitektur

1. CSP-Modellierungsrahmen

Verwendung von Communicating Sequential Processes (CSP) als formale Modellierungssprache:

  • Prozesse: Abstrakte Komponenten, definiert durch die von ihnen ausgeführten Ereignisse
  • Ereignisse: Atomare, synchrone, instantane Kommunikationsvorgänge
  • Kanäle: Medien für die Kommunikation zwischen Prozessen

2. Modellierung des Planungssystems

SCHEDULER = 
  rqdequeue?p → -- Einen Prozess aus der Warteschlange entfernen
  run.p → -- Ihn ausführen
  yield.p → -- Auf Nachgeben warten
  SCHEDULER -- Rekursion

SCHEDULE_MANAGER = 
  schedule?pid → -- Auf Planungsereignis warten
  rqenqueue!pid → -- Prozess in Warteschlange einreihen
  SCHEDULE_MANAGER -- Rekursion

3. Modellierung von Prozessmetadaten

Jeder Prozess benötigt einen Monitor, ein Ausführungs-Flag und ein Bereitschafts-Flag:

PROCESS(p) = 
  VARIABLE(ready.p, true)
  ||| VARIABLE(running.p, false)
  ||| MONITOR(claim_process.p, release_process.p)

4. Modellierung gemeinsamer Kanäle

  • Viele-zu-Eins-Kanäle: Mehrere Schreibprozesse, ein Leseprozess
  • Eins-zu-Viele-Kanäle: Ein Schreibprozess, mehrere Leseprozesse
  • Viele-zu-Viele-Kanäle: Mehrere Schreibprozesse, mehrere Leseprozesse

Technische Innovationen

1. Verifikationsmethode unter Berücksichtigung der Planungsumgebung

Im Gegensatz zu traditionellen Methoden modelliert dieses Papier den kooperativen Planer während des Verifikationsprozesses explizit, was es ermöglicht, Probleme zu entdecken, die nur unter bestimmten Planungsbedingungen auftreten.

2. Verfeinerungsprüfung unter Ressourcenbeschränkungen

Durch Variation der Planerzahl wurde untersucht, wie sich das Systemverhalten unter verschiedenen Ressourcenkonfigurationen ändert, und es wurde die Beziehung zwischen Ressourcenausreichendheit und Korrektheit entdeckt.

3. Bidirektionale Übersetzung von Implementierung zu Spezifikation

  • ProcessJ-Code → Java-Code → CSP-Modell
  • Etablierung einer vollständigen Übersetzungskette zur Gewährleistung der Zuverlässigkeit der Verifikationsergebnisse

Experimentelle Einrichtung

Verifikationswerkzeuge

  • FDR (Failures-Divergences Refinement): CSP-Verfeinerungsprüfwerkzeug
  • CSPM: Maschinenlesbares CSP-Format

Verifikationsmodelle

Verwendung von drei semantischen Modellen für die Analyse:

  1. Traces-Modell: Basierend auf externem beobachtbarem Verhalten
  2. Stable Failures-Modell: Behandlung von Ereignissen, die Prozesse möglicherweise ablehnen
  3. Failures-Divergences-Modell: Behandlung potenzieller Livelock-Szenarien

Testkonfigurationen

  • Prozesskonfigurationen: Verschiedene Kombinationen von 1-2 Schreibprozessen und 1-3 Leseprozessen
  • Planerzahl: 1 bis 4 Planer
  • Kanaltypen: Eins-zu-Viele-, Viele-zu-Eins- und Viele-zu-Viele-Kanäle

Experimentelle Ergebnisse

Hauptergebnisse

| Kanaltyp | Prozesskonfiguration | Gesamtprozesse | Planerzahl ||||| |----------|----------------------|----------------|--|--|--|--| | | | | 1| 2| 3| 4| | Eins-zu-Viele | 1 Schreib-2 Les | 3 | T| T| F| F| | Eins-zu-Viele | 1 Schreib-3 Les | 4 | T| T| T| F| | Viele-zu-Eins | 2 Schreib-1 Les | 3 | T| T| F| F| | Viele-zu-Eins | 3 Schreib-1 Les | 4 | T| T| T| F| | Viele-zu-Viele | 2 Schreib-2 Les | 4 | T| T| T| F|

Symbolerklärung:

  • T = Traces-Verfeinerungsprüfung bestanden
  • F = Failures-Verfeinerungsprüfung bestanden
  • ✗ = Verfeinerungsprüfung fehlgeschlagen

Wichtigste Erkenntnisse

  1. Ressourcenausreichendheitssatz: Wenn die Planerzahl gleich oder größer als die Gesamtzahl der Prozesse ist, kann Verfeinerung in beide Richtungen im Failures-Modell erreicht werden.
  2. Auswirkungen unzureichender Ressourcen:
    • Bei unzureichenden Planern kann nur Traces-Verfeinerung erreicht werden, nicht Failures-Verfeinerung
    • Dies bedeutet nicht, dass das System deadlockt, sondern dass bestimmte Traces nicht mehr realisierbar sind
  3. Auswirkungen der Planungswarteschlange: Die Laufwarteschlange erzeugt eine natürliche Ordnung für Prozesse. Wenn Planer unzureichend sind, sind die Akzeptanzmengen bestimmter Prozesse nicht in der Gesamtakzeptanzmenge des Systems enthalten.

Verwandte Arbeiten

Bereich der formalen Verifikation

  • CSO- und JCSP-Verifikation: Frühere Arbeiten verifizierten andere Laufzeitsysteme, ignorierten aber die Ausführungsumgebung
  • SPIN-Modellprüfung: Andere Systeme verwenden ähnliche Verifikationsmethoden, gehen aber typischerweise von präemptiver Planung aus

Forschung zu kooperativer Planung

  • occam-π-Planer: Der ProcessJ-Planer ähnelt dem kooperativen Multiprozessor-Planer von occam-π
  • Async/Await-Muster: Kooperatives Multitasking wird in JavaScript, Python, C++ und Rust zunehmend populär

Vorteile dieses Papiers

  1. Erste Berücksichtigung der Planungsumgebung: Explizite Modellierung des kooperativen Planers in der Verifikation
  2. Entdeckung planungsbezogener Probleme: Fähigkeit zur Erkennung von Problemen wie Livelocks, die nur unter bestimmten Planungsbedingungen auftreten
  3. Ressourcenbewusste Verifikation: Quantifizierung der Beziehung zwischen Ressourcenbedarf und Korrektheit

Schlussfolgerungen und Diskussion

Hauptschlussfolgerungen

  1. Implementierungskorrektheit: Die Implementierung gemeinsamer Kanäle in ProcessJ ist mit ausreichenden Planern korrekt.
  2. Ressourcenabhängigkeit: Korrektes Verhalten hängt davon ab, dass ausreichende Planungsressourcen zur Ausführung aller relevanten Prozesse verfügbar sind.
  3. Notwendigkeit der Modellierung: Die Modellierung der Laufzeitumgebung ist notwendig, um sicherzustellen, dass Komponenten in der realen Welt gemäß Spezifikation verhalten.

Einschränkungen

  1. Verwendung von Sperren: Die aktuelle Implementierung nutzt umfangreich Sperren/Monitore, was die Nebenläufigkeit und Leistung beeinträchtigen kann.
  2. Planerbedarf: Die Anforderung einer Planerzahl gleich der Prozessprozessanzahl kann in praktischen Anwendungen unrealistisch sein.
  3. Verifikationskomplexität: Der Zustandsraum der Verifikation wächst mit zunehmender Prozessprozessanzahl schnell.

Zukünftige Richtungen

  1. Sperrfreie Implementierung:
    • Verwendung atomarer Variablen anstelle von Sperren
    • Implementierung sperrfreier Warteschlangenstrukturen
    • Entwicklung von CSP-Modellen, die Compare-and-Swap-Operationen unterstützen
  2. Vereinfachung der Spezifikation:
    • Entwicklung leichtgewichtiger CSP-Modellkonstruktionsmethoden
    • Untersuchung des ProcessJ-Verhaltens unter verschiedenen Planungsbedingungen
  3. Planer-Optimierung:
    • Untersuchung, ob Failures-Verfeinerung mit weniger als der Prozessprozessanzahl von Planern erreicht werden kann
    • Analyse des Planerbedarfs verschiedener Programme

Tiefgreifende Bewertung

Stärken

  1. Methodische Innovation:
    • Erste Berücksichtigung der kooperativen Planungsumgebung in der formalen Verifikation
    • Etablierung einer vollständigen Verifikationskette von Implementierung zu Spezifikation
  2. Theoretische Beiträge:
    • Bereitstellung eines strengen algebraischen Beweises für die Spezifikation gemeinsamer Kanäle
    • Quantifizierung der Beziehung zwischen Ressourcenbedarf und Korrektheit
  3. Praktischer Wert:
    • Verifikation der Korrektheit tatsächlicher Laufzeitsysteme
    • Bereitstellung von Verifikationsmethoden für andere kooperativ geplante Systeme
  4. Experimentelle Vollständigkeit:
    • Test verschiedener Kanalkonfigurationen und Planerzahlen
    • Verwendung strenger CSP/FDR-Verifikationsmethoden

Schwächen

  1. Skalierungsprobleme:
    • Verifikationskomplexität wächst exponentiell mit der Prozessprozessanzahl
    • Anforderung großer Planerzahlen kann praktische Anwendungen einschränken
  2. Unzureichende Leistungsüberlegungen:
    • Umfangreiche Sperrnutzung kann Systemleistung beeinträchtigen
    • Unzureichende Diskussion des Verifikationsmehraufwands
  3. Begrenzte Anwendbarkeit:
    • Hauptsächlich auf die Sprache ProcessJ ausgerichtet
    • Anwendbarkeit auf andere kooperativ geplante Systeme erfordert weitere Verifikation

Auswirkungen

  1. Akademischer Beitrag:
    • Bereitstellung neuer Verifikationsideen für die Bereiche Programmiersprachen und formale Methoden
    • Förderung der Entwicklung von Verifikationsmethoden, die die Ausführungsumgebung berücksichtigen
  2. Praktischer Wert:
    • Verbesserung der Zuverlässigkeit der ProcessJ-Laufzeit
    • Bereitstellung von Referenzen für die Verifikation von Laufzeitsystemen anderer Sprachen
  3. Reproduzierbarkeit:
    • Bereitstellung vollständiger CSP-Codes und Testskripte
    • Verifikationsprozess und Ergebnisse können unabhängig reproduziert werden

Anwendungsszenarien

  1. Prozessorientierte Programmiersprachen: Besonders geeignet für die Verifikation von Laufzeitsystemen von Sprachen mit CSP-Semantik
  2. Kooperativ geplante Systeme: Anwendbar auf andere nebenläufige Systeme mit kooperativer Planung
  3. Kritische Systementwicklung: Geeignet für die Entwicklung nebenläufiger Systeme mit hohen Anforderungen an Korrektheit

Literaturverzeichnis

Dieses Papier zitiert 51 verwandte Arbeiten, hauptsächlich einschließlich:

  1. CSP-Grundlagentheorie: Klassische CSP-Werke von Hoare und verwandte Theorie
  2. Formale Verifikationswerkzeuge: FDR-Werkzeug und verwandte Verifikationsmethoden
  3. Nebenläufige Programmiersprachen: Verwandte Forschung zu JCSP, occam-π, Go, Erlang und anderen Sprachen
  4. Planungsalgorithmen: Verwandte Arbeiten zu gegenseitigen Ausschlussalgorithmen und nebenläufigen Algorithmen
  5. Frühere Arbeiten der Autoren: Reihe von Forschungsarbeiten zur Verifikation der ProcessJ-Laufzeit

Zusammenfassung: Dieses Papier leistet einen wichtigen Beitrag im Bereich der formalen Verifikation, insbesondere bei der Verifikation nebenläufiger Systeme unter Berücksichtigung der Ausführungsumgebung. Obwohl es einige Einschränkungen gibt, haben seine Methoden und Erkenntnisse wichtigen Wert für die Verbesserung der Zuverlässigkeit nebenläufiger Systeme.