Synchronizität ist ein Mythos

Hallo an alle!

Heute finden Sie einen langen Text ohne Bilder (im Vergleich zum Original leicht gekürzt), in dem die in der Überschrift dargelegte These detailliert analysiert wird. Microsoft-Veteran Terry Crowley beschreibt die Essenz der asynchronen Programmierung und erklärt, warum dieser Ansatz viel realistischer und angemessener ist als synchron und sequentiell.

Wer ein Buch schreiben möchte oder denkt, das solche Themen berührt, schreibt persönlich.

Synchronizität ist ein Mythos. Nichts passiert sofort. Alles braucht Zeit.
Einige Eigenschaften von Computersystemen und Programmierumgebungen beruhen im Wesentlichen auf der Tatsache, dass Berechnungen in der dreidimensionalen physikalischen Welt stattfinden und durch die Grenzen der Lichtgeschwindigkeit und die Gesetze der Thermodynamik begrenzt sind.

Eine solche Verwurzelung in der physischen Welt bedeutet, dass einige Aspekte auch mit dem Aufkommen neuer Technologien, die neue Möglichkeiten und Zugang zu neuen Grenzen der Produktivität bieten, nicht an Relevanz verlieren. Sie bleiben gültig, weil sie nicht nur „während des Entwurfs gewählte Optionen“ sind, sondern die zugrunde liegende Realität des physischen Universums.

Der Unterschied zwischen Synchronität und Asynchronität in der Sprache und der Schaffung von Systemen ist genau ein Aspekt des Designs, der tiefe physikalische Grundlagen hat. Die meisten Programmierer beginnen sofort mit solchen Programmen und Sprachen zu arbeiten, bei denen eine synchrone Ausführung impliziert ist. Tatsächlich ist dies so natürlich, dass niemand direkt darüber spricht oder spricht. Der Begriff „synchron“ bedeutet in diesem Zusammenhang, dass die Berechnung wie eine Reihe aufeinanderfolgender Schritte sofort erfolgt und nichts anderes passiert, bevor sie abgeschlossen ist. Ich führe “c = a + b” “x = f(y)” - und nichts anderes wird passieren, bis diese Anweisung abgeschlossen ist.

Natürlich passiert im physischen Universum nichts sofort. Alle Prozesse sind mit einigen Verzögerungen verbunden. Sie müssen in der Speicherhierarchie navigieren, einen Prozessorzyklus ausführen, Informationen von einem Festplattenlaufwerk lesen oder über das Netzwerk eine Verbindung zu einem anderen Knoten herstellen, was ebenfalls zu Verzögerungen bei der Datenübertragung führt. All dies ist eine grundlegende Folge der Lichtgeschwindigkeit und der Signalausbreitung in drei Dimensionen.

Alle Prozesse sind etwas spät, alles braucht Zeit. Wenn wir einige Prozesse als synchron definieren, sagen wir im Wesentlichen, dass wir diese Verzögerung ignorieren und unsere Berechnung als augenblicklich beschreiben werden. Tatsächlich wird in Computersystemen häufig eine seriöse Infrastruktur eingerichtet, die es Ihnen ermöglicht, die grundlegende Hardware weiterhin aktiv zu nutzen, selbst wenn versucht wird, die Programmierschnittstelle zu optimieren, indem die darauf auftretenden Ereignisse als synchron dargestellt werden.

Die bloße Vorstellung, dass die Synchronisation über einen speziellen Mechanismus erfolgt und mit Kosten verbunden ist, mag für den Programmierer unlogisch erscheinen, der eher daran gewöhnt ist, dass Asynchronität eine aktive externe Steuerung erfordert. Tatsächlich passiert dies tatsächlich, wenn eine asynchrone Schnittstelle bereitgestellt wird: Eine echte grundlegende Asynchronität öffnet sich für den Programmierer etwas deutlicher als zuvor, und er muss sie manuell verarbeiten, anstatt sich auf ein Programm zu verlassen, das dies automatisch tun könnte. Die direkte Bereitstellung von Asynchronität ist mit zusätzlichen Kosten für den Programmierer verbunden, ermöglicht es Ihnen jedoch gleichzeitig, die in diesem Themenbereich enthaltenen Kosten und Kompromisse kompetenter zu verteilen, und überlässt dies nicht einem System, das solche Kosten und Kompromisse ausgleichen würde. Die asynchrone Schnittstelle entspricht häufig genauer Ereignissen, die physikalisch im Basissystem auftreten, und eröffnet dementsprechend zusätzliche Optimierungsmöglichkeiten.

Beispielsweise erhalten der Prozessor und das Speichersystem eine angemessene Infrastruktur, die für das Lesen und Schreiben von Daten im Speicher unter Berücksichtigung ihrer Hierarchie verantwortlich ist. Auf Ebene 1 (L1) kann die Cache-Verbindung mehrere Nanosekunden dauern, während die Speicherverbindung selbst den gesamten Weg durch L2, L3 und den Hauptspeicher durchlaufen muss, was Hunderte von Nanosekunden dauern kann. Wenn Sie nur warten, bis die Speicherverbindung aufgelöst ist, ist der Prozessor für einen erheblichen Prozentsatz der Zeit inaktiv.

Zur Optimierung solcher Phänomene werden schwerwiegende Mechanismen verwendet: Pipelining mit einer führenden Ansicht des Befehlsstroms, gleichzeitiges Abrufen mehrerer Vorgänge aus dem Speicher und der aktuellen Datenspeicherung, Verzweigungsvorhersage und Versuche, das Programm weiter zu optimieren, selbst wenn es zu einem anderen Speicherort springt, genaue Kontrolle der Speicherbarrieren, um dies zu gewährleisten dass all dieser komplexe Mechanismus weiterhin ein konsistentes Speichermodell für eine übergeordnete Programmierumgebung bereitstellen wird. All diese Dinge werden unternommen, um die Leistung zu optimieren und die Hardware maximal zu nutzen, um diese Verzögerungen von 10 bis 100 Nanosekunden in der Speicherhierarchie zu verbergen und ein System bereitzustellen, in dem eine synchrone Ausführung stattfinden soll, während gleichzeitig die Leistung des Prozessorkerns beeinträchtigt wird.

Es ist keineswegs immer klar, wie effektiv solche Optimierungen für einen bestimmten Code sind, und zur Beantwortung dieser Frage sind häufig sehr spezifische Tools zur Leistungsanalyse erforderlich. Solche analytischen Arbeiten sind bei der Entwicklung einiger sehr wertvoller Codes vorgesehen (z. B. in der Konvertierungs-Engine für Excel, einigen Komprimierungsoptionen im Kernel oder kryptografischen Pfaden im Code).

Operationen mit einer größeren Verzögerung, beispielsweise das Lesen von Daten von einer rotierenden Platte, erfordern die Verwendung anderer Mechanismen. In solchen Fällen muss beim Anfordern des Lesens von der Betriebssystemfestplatte vollständig zu einem anderen Thread oder Prozess gewechselt werden, und die synchrone Anforderung bleibt nicht gesendet. Die hohen Kosten für das Umschalten und Unterstützen dieses Mechanismus als solchen sind akzeptabel, da die in diesem Fall verborgene Latenz mehrere Millisekunden anstelle von Nanosekunden erreichen kann. Bitte beachten Sie: Diese Kosten reduzieren sich nicht auf das einfache Wechseln zwischen Threads, sondern umfassen die Kosten aller Speicher und Ressourcen, die tatsächlich inaktiv bleiben, bis der Vorgang abgeschlossen ist. All diese Kosten müssen anfallen, um eine vermeintlich synchrone Schnittstelle bereitzustellen.

Es gibt eine Reihe grundlegender Gründe, warum es erforderlich sein kann, die tatsächliche grundlegende Asynchronität im System aufzudecken, und für die es vorzuziehen wäre, eine asynchrone Schnittstelle mit einer bestimmten Komponente, Ebene oder Anwendung zu verwenden, selbst unter Berücksichtigung der Notwendigkeit, die zunehmende Komplexität direkt zu bewältigen.

Parallelität Wenn die bereitgestellte Ressource auf echte Parallelität ausgelegt ist, kann der Client über die asynchrone Schnittstelle auf natürliche Weise gleichzeitig mehrere Anforderungen ausgeben und verwalten, um die grundlegenden Ressourcen voll auszunutzen.

Beförderung . Der übliche Weg, um die tatsächliche Verzögerung auf einer Schnittstelle zu verringern, besteht darin, sicherzustellen, dass mehrere Anforderungen gleichzeitig auf den Versand warten (wie viel dies für die Leistung tatsächlich nützlich ist, hängt davon ab, woher wir die Quelle der Verzögerung beziehen). In jedem Fall kann, wenn das System für das Pipelining angepasst ist, die tatsächliche Verzögerung um einen Faktor reduziert werden, der der Anzahl der Anforderungen entspricht, die auf das Senden warten. Es kann also 10 ms dauern, bis eine bestimmte Anforderung abgeschlossen ist. Wenn Sie jedoch 10 Anforderungen in die Pipeline schreiben, kann die Antwort jede Millisekunde erfolgen. Der Gesamtdurchsatz ist eine Funktion des verfügbaren Pipelining und nicht nur eine Durchlaufverzögerung pro Anforderung. Eine synchrone Schnittstelle, die eine Anforderung ausgibt und auf eine Antwort wartet, führt immer zu einer höheren End-to-End-Verzögerung.

Verpackung (lokal oder fern) . Die asynchrone Schnittstelle bietet auf natürlichere Weise die Implementierung eines Abfrageverpackungssystems entweder lokal oder auf einer Remote-Ressource (Hinweis: In diesem Fall kann die „Festplatte“ am anderen Ende der E / A-Schnittstelle „Remote“ sein). Tatsache ist, dass die Anwendung den Empfang der Antwort bereits bewältigen sollte und gleichzeitig eine gewisse Verzögerung auftritt, da die Anwendung die aktuelle Verarbeitung nicht unterbricht. Eine solche zusätzliche Verarbeitung kann mit zusätzlichen Anforderungen verbunden sein, die natürlich gebündelt würden.

Lokale Stapelverarbeitung kann eine effizientere Übertragung von Anforderungsserien oder sogar die Komprimierung und Entfernung doppelter Anforderungen direkt auf dem lokalen Computer ermöglichen. Um gleichzeitig auf eine ganze Reihe von Anforderungen auf einer Remote-Ressource zugreifen zu können, ist möglicherweise eine ernsthafte Optimierung erforderlich. Ein klassisches Beispiel: Ein Plattencontroller ordnet eine Reihe von Lese- und Schreibvorgängen neu an, um die Position des Plattenkopfs auf einer rotierenden Platte auszunutzen und die Kopfvorschubzeit zu minimieren. Auf jeder Datenspeicherschnittstelle, die auf Blockebene ausgeführt wird, können Sie die Leistung erheblich verbessern, indem Sie eine Reihe von Abfragen bündeln, bei denen alle Lese- und Schreibvorgänge auf denselben Block fallen.

Natürlich kann lokales Packaging auch auf einer synchronen Schnittstelle implementiert werden, aber dafür müssen Sie entweder die Wahrheit weitgehend „verbergen“ oder die Paketpaketierung als Besonderheit der Schnittstelle programmieren, was den gesamten Client erheblich komplizieren kann. Ein klassisches Beispiel für das Verstecken der Wahrheit ist gepufferte E / A. Die Anwendung ruft “write(byte)” , und die Schnittstelle gibt den success zurück. Tatsächlich wird der Datensatz selbst (sowie Informationen darüber, ob er erfolgreich übergeben wurde) jedoch erst ausgeführt, wenn der Puffer explizit gefüllt oder leer ist. Dies geschieht, wenn die Datei geschlossen wird . Viele Anwendungen können solche Details ignorieren - ein Durcheinander tritt nur auf, wenn die Anwendung einige interagierende Abfolgen von Vorgängen sowie eine genaue Vorstellung davon, was auf den unteren Ebenen geschieht, gewährleisten muss.

Entsperren / Entfesseln . Eine der häufigsten Anwendungen der Asynchronität im Kontext grafischer Benutzeroberflächen besteht darin, zu verhindern, dass der Hauptthread der Benutzeroberfläche blockiert wird, damit der Benutzer weiterhin mit der Anwendung interagieren kann. Verzögerungen im Langzeitbetrieb (z. B. Netzwerkkommunikation) können nicht hinter einer synchronen Schnittstelle verborgen werden. In diesem Fall muss der Benutzeroberflächenthread solche asynchronen Vorgänge explizit verwalten und die zusätzliche Komplexität bewältigen, die in das Programm eingeführt wird.

Die Benutzeroberfläche ist nur ein Beispiel dafür, dass die Komponente weiterhin auf zusätzliche Anforderungen reagieren muss und sich daher nicht auf einen Standardmechanismus verlassen kann, der Verzögerungen verbirgt, um die Arbeit des Programmierers zu vereinfachen.
Eine Webserverkomponente, die neue Verbindungen zu Sockets empfängt, überträgt eine solche Verbindung in der Regel sehr schnell an eine andere asynchrone Komponente, die die Kommunikation auf dem Socket bereitstellt, und kehrt selbst zur Verarbeitung neuer Anforderungen zurück.

In synchronen Modellen sind Komponenten und ihre Verarbeitungsmodelle normalerweise eng miteinander verbunden.
Asynchrone Wechselwirkungen sind ein Mechanismus, der häufig zur Lockerung der Bindung verwendet wird .

Kostensenkung und Management. Wie oben erwähnt, beinhaltet jeder Mechanismus zum Ausblenden der Asynchronität eine gewisse Ressourcenzuweisung und einen gewissen Overhead. Für eine bestimmte Anwendung ist ein solcher Overhead möglicherweise nicht akzeptabel, und der Entwickler dieser Anwendung muss einen Weg finden, um die natürliche Asynchronität zu steuern.

Ein interessantes Beispiel ist die Geschichte der Webserver. Frühe Webserver (auf Unix aufgebaut) verwendeten normalerweise einen separaten Prozess, um eingehende Anforderungen zu verwalten. Dann konnte dieser Prozess diese Verbindung lesen und darauf schreiben, es geschah im Wesentlichen synchron. Ein solches Design entwickelte sich und die Kosten wurden reduziert, als Threads anstelle von Prozessen verwendet wurden, aber das gesamte synchrone Ausführungsmodell blieb erhalten. Bei modernen Entwurfsoptionen wird anerkannt, dass das Hauptaugenmerk nicht auf das Berechnungsmodell gelegt werden sollte, sondern vor allem auf die zugehörige Eingabe / Ausgabe in Bezug auf Lesen und Schreiben beim Austausch von Informationen mit einer Datenbank, einem Dateisystem oder der Übertragung von Informationen über ein Netzwerk, während eine Antwort formuliert wird . In der Regel werden hierfür Arbeitswarteschlangen verwendet, in denen eine bestimmte Begrenzung der Anzahl der Threads zulässig ist - und in diesem Fall ist es möglich, das Ressourcenmanagement klarer zu gestalten.

Der Erfolg von NodeJS bei der Backend-Entwicklung erklärt sich nicht nur aus der Unterstützung dieser Engine durch zahlreiche JavaScript-Entwickler, die mit der Erstellung von Client-Webschnittstellen aufgewachsen sind. In NodeJS wird wie in der Browser-Skripterstellung besonderes Augenmerk auf das asynchrone Entwerfen gelegt, was gut zu typischen Serverladeoptionen passt: Die Verwaltung der Serverressourcen hängt in erster Linie von der E / A und nicht von der Verarbeitung ab.

Es gibt noch einen weiteren interessanten Aspekt: ​​Solche Kompromisse werden vom Anwendungsentwickler expliziter und besser angepasst, wenn Sie sich an den asynchronen Ansatz halten. In dem Beispiel mit Verzögerungen in der Speicherhierarchie nahm die tatsächliche Verzögerung (gemessen in Prozessorzyklen als Anforderung im Speicher) über mehrere Jahrzehnte dramatisch zu. Prozessorentwickler haben Schwierigkeiten, immer neue Cache-Ebenen und zusätzliche Mechanismen hinzuzufügen, die das vom Prozessor bereitgestellte Speichermodell zunehmend vorantreiben, damit das Erscheinungsbild der synchronen Verarbeitung weiter erhalten bleibt.

Die Kontextumschaltung an den Grenzen synchroner E / A ist ein weiteres Beispiel, bei dem sich die tatsächlichen Kompromisse im Laufe der Zeit dramatisch geändert haben. Die Zunahme der Prozessorzyklen ist schneller als der Kampf gegen Verzögerungen, und dies bedeutet, dass der Anwendung jetzt viel mehr Rechenfähigkeiten fehlen, während sie in gesperrter Form im Leerlauf ist und auf den Abschluss der E / A wartet. Das gleiche Problem im Zusammenhang mit den relativen Kosten von Kompromissen hat OS-Entwickler dazu veranlasst, sich an Speicherverwaltungsschemata zu halten, die früheren Modellen mit Prozessaustausch (bei denen das gesamte Prozessabbild vollständig in den Speicher geladen wird und nach dem der Prozess startet) viel ähnlicher sind, anstatt sich auszutauschen Seiten. Es ist zu schwierig, Verzögerungen zu verbergen, die am Rand jeder Seite auftreten können. Der dramatisch verbesserte Gesamtdurchsatz, der mit großen sequentiellen E / A-Anforderungen erzielt wird (im Vergleich zur Verwendung zufälliger Anforderungen), trägt ebenfalls zu solchen Änderungen bei.

Andere Themen

Abbrechen

Stornierung ist ein komplexes Thema . In der Vergangenheit haben synchron ausgerichtete Systeme bei der Stornierungsverarbeitung schlechte Arbeit geleistet, und einige unterstützten die Stornierung überhaupt nicht. Die Stornierung musste im Wesentlichen "out of band" ausgelegt sein, für eine solche Operation musste ein separater Ausführungsthread aufgerufen werden. Als Alternative eignen sich asynchrone Modelle, bei denen die Unterstützung der Stornierung natürlicher organisiert ist, insbesondere wird ein derart trivialer Ansatz verwendet: Sie ignoriert einfach, welche Antwort letztendlich zurückkehrt (und ob sie überhaupt zurückkehrt). Die Stornierung wird immer wichtiger, wenn die Variabilität der Verzögerungen zunimmt, und in der Praxis nimmt auch die Fehlerrate zu - ein sehr guter historischer Ausschnitt, der zeigt, wie sich unsere Netzwerkumgebungen entwickelt haben.

Drosselung / Ressourcenmanagement

Das synchrone Design führt per Definition zu einer gewissen Drosselung, wodurch verhindert wird, dass die Anwendung zusätzliche Anforderungen ausgibt, bis die aktuelle Anforderung abgeschlossen ist. In einem asynchronen Entwurf erfolgt die Drosselung nicht umsonst, daher ist es manchmal erforderlich, sie explizit zu implementieren. In diesem Beitrag wird die Situation mit Word Web App als Beispiel beschrieben, in der der Übergang vom synchronen zum asynchronen Entwurf schwerwiegende Probleme bei der Ressourcenverwaltung verursachte. Wenn die Anwendung eine synchrone Schnittstelle verwendet, erkennt sie möglicherweise nicht, dass die Drosselung implizit in den Code eingebettet ist. Wenn Sie eine solche implizite Drosselung entfernen, ist es möglich (oder erforderlich), das Ressourcenmanagement expliziter zu organisieren.

Ich musste mich gleich zu Beginn meiner Karriere damit befassen, als wir einen Texteditor von Suns synchroner grafischer API auf X Windows portierten. Bei Verwendung der Sun-API war der Rendervorgang synchron, sodass der Client die Kontrolle erst nach Abschluss wiedererlangte. In X Windows wurde eine grafische Anforderung asynchron über eine Netzwerkverbindung gesendet und dann vom Anzeigeserver (der sich auf demselben oder einem anderen Computer befinden kann) ausgeführt.

Um eine gute interaktive Leistung zu gewährleisten, sollte unsere Anwendung ein gewisses Rendering bereitstellen (dh sicherstellen, dass die Zeile, in der sich der Cursor jetzt befindet, aktualisiert und gerendert wird), und dann prüfen, ob andere Tastatureingaben gelesen werden müssen. , ( , ), , . API. , , - . , . UI , .

, 30 (-, Facebook iPhone ). – ( , ), , . , , .



, . , Microsoft, , API – , , . , , – : «, !» , , .

, . – , . , : , , , . , - . , , async/await . «» , , , JavaScript. : , . Async/await , , . . , , , .

. , , . , , , . , , ( !). () , , .

, . , . async/await, , , , .

, , , – . , . – , , , ( , – Word Excel). , , - , , , .
, , , , .
, – . .

Schlussfolgerungen

. – , , . , , , . , ; , .