Zusammenfassung

  • Der erste öffentliche W3C-Entwurf vom 5. Januar 2023 beschrieb asynchron angeforderte Locks mit frei gewählten Namen für Fenster und Worker, die einen Speicherbereich teilen. Der Entwurf vom 24. September 2025 behielt die Grundfolge bei: anfordern, arbeiten, nach Ende der Aufgabe freigeben.
  • Ein exklusiver Lock hält andere Inhaber desselben Namens draußen; kompatible gemeinsame Locks können parallel bestehen. Die Ausnahme steal entzieht einem bisherigen Inhaber den Lock, beendet dessen laufenden Code aber nicht zwingend.

Eine Web-Anwendung besteht selten nur aus dem einen Tab, den ein Entwickler vor sich sieht. Nutzer öffnen Fenster mehrfach. Ein Worker räumt im Hintergrund auf. Jeder Teil kann einen lokalen Zwischenspeicher ändern oder einen Synchronisierungslauf starten. Läuft derselbe Auftrag zweimal, kann jede einzelne Oberfläche trotzdem tadellos aussehen. Das Problem braucht einen gemeinsamen Treffpunkt für die Beteiligten. Der Browser beherbergt sie bereits.

Der erste öffentliche W3C-Arbeitsentwurf vom 5. Januar 2023 definiert einen asynchronen Lock für eine benannte Ressource. Ein Skript erhält ihn, führt Arbeit aus und gibt ihn danach frei. Das gilt für kooperierende Fenster und Worker innerhalb eines gemeinsamen Storage-Buckets. Den Ressourcennamen wählt die Anwendung. sync-akte bezeichnet ihre eigene Vereinbarung über eine Aufgabe; es ist weder ein Dateiname, den der Browser sperrt, noch ein Urteil über das spätere Ergebnis.

Die W3C-Veröffentlichungsgeschichte führt den ersten Entwurf von 2023 und einen weiteren Working Draft vom September 2025 auf. Der Entwurf vom 24. September 2025 beschreibt die Benutzung in drei Schritten. Ein Skript fordert an. Es arbeitet in einer asynchronen Aufgabe. Wenn diese endet, wird der Lock frei. Als Beispiel dient ein Dokumenteneditor mit demselben Dokument in zwei Tabs. Deren lokale Speicherung und Synchronisierung müssen abgestimmt werden. Ein weiterer Fall bestimmt einen Haupt-Tab für Aufräumarbeiten; nach dessen Ende kann ein wartender Tab übernehmen.

Die Betriebsart beantwortet eine einfache Frage: Wer darf jetzt hinein? Beim exklusiven Lock bekommt genau ein Inhaber den Namen. Das passt zu einer einzelnen Aktualisierung des lokalen Zustands. Beim gemeinsamen Lock können mehrere kompatible Inhaber gleichzeitig lesen. Ein exklusiver Schreiber wartet, bis sie fertig sind. Der Browser kennt nur Namen und Modi. Geben zwei Programmteile derselben Aufgabe unterschiedliche Namen, entstehen zwei Schranken. Beide gehen durch, und die Abstimmung fällt aus.

Das Erklärdokument im W3C-Spezifikationsrepository zeigt Arbeit innerhalb eines Callbacks; das Ergebnis der Anfrage folgt dem Ergebnis dieser Funktion. Eine Zustandsabfrage listet gehaltene und wartende Locks, liefert aber nur ein vergängliches Bild. Das Dokument zeigt außerdem, wie ein Deadlock entsteht: Programm eins hält A und wartet auf B, Programm zwei hält B und wartet auf A. Der Browser kann beide Warteschlangen korrekt führen und dennoch zwei Gäste beherbergen, die einander nie die Tür öffnen.

Besonders scharf ist steal. Nach dem Entwurf von 2025 entfernt eine neue Anfrage bereits vergebene Locks desselben Namens und überholt die Warteschlange. Der Freigabe-Promise des alten Locks wird mit AbortError zurückgewiesen. Die laufende Callback-Arbeit im alten Tab wird dadurch nicht automatisch angehalten. Sie kann weiter schreiben, während der neue Inhaber ebenfalls arbeitet. Erst die Anwendung kann auf den Verlust reagieren und ihre alte Arbeit beenden oder deren Ergebnis verwerfen. Die Schranke hat den neuen Gast eingelassen, obwohl der vorige noch im Raum steht.

Die Schranke steht innerhalb eines klaren Bereichs: bei Agenten, die im selben Browser einen Storage-Bucket teilen. Andere Profile, private Sitzungen und Geräte haben andere Lock-Manager. Die vier Originalquellen erklären die Schnittstelle und ihre Entwurfsdaten. Ob ein konkretes Update richtig gespeichert wurde, belegt erst die Anwendung. Der Lock ordnet den Beginn; die Abnahme der Arbeit geschieht hinter der Tür.