Wie entwerfe ich gleichzeitige Datenstrukturen?

Ich habe diese Frage zuvor auf Programmers.SE ohne Erfolg gestellt.

Ich suche nach schriftlichen Lernressourcen zum Entwerfen gleichzeitiger Datenstrukturen. Ich interessiere mich mehr für den Entwurfsprozess (z. B. die Identifizierung der richtigen Invarianten) als für das Endprodukt (eine vollständige Codeliste).

Ein konkretes Beispiel: Chris Okasakis Buch „Rein funktionale Datenstrukturen“ hat mir sehr gut gefallen, da es mehr als nur eine Referenz ist - es führt den Leser durch das Design seiner Datenstrukturen und Algorithmen. Oft motiviert das Buch ein kniffliges oder nicht offensichtliches Design, indem es zuerst eine naivere Version gibt und diese erst dann verfeinert, bis die gewünschte zeitliche Komplexität (entweder im schlimmsten Fall oder amortisiert) erreicht ist. So etwas suche ich.

Damit:

1. Welche Techniken oder Heuristiken gibt es zum Entwerfen gleichzeitiger Datenstrukturen?

2. Gibt es Bücher, Artikel, Blog-Beiträge, Tutorials usw., die diese Techniken und Heuristiken erklären?

Obwohl ich in diesem Bereich nicht viel gelesen habe, fand ich die Kunst der Multiprozessor-Programmierung von Maurice Herlihy und Nir Shavit als hilfreiche Einführung und Übersicht über Techniken. Es werden verschiedene Algorithmen, Gründe für ihre Funktionsweise und die Kompromisse, Merkmale und Einschränkungen der verschiedenen Ansätze untersucht. Obwohl es einen gewissen Formalismus hat, erwarte ich, dass es ein ziemlich einführender und zugänglicher Text ist.

Um einen Eindruck vom Text zu bekommen, hier die Einführung in den Abschnitt über Atomregister aus der Ausgabe 2008:

Der naheliegende Ausgangspunkt ist die Frage, ob wir den Konsens mithilfe von Atomregistern lösen können. Überraschenderweise lautet die Antwort vielleicht nein. Wir werden zeigen, dass es für zwei Threads kein binäres Konsensprotokoll gibt. Wir lassen es als Übung, um zu zeigen, dass, wenn zwei Threads keinen Konsens über zwei Werte erzielen können, nThreads keinen Konsens über kWerte erzielen können, wo n > 2und k > 2.

Die Antwort ist nicht so einfach wie die funktionale Programmierung. In der funktionalen Programmierung haben wir hier ein allgemeines Konzept der funktionalen Programmierung, und die Spezifikation der Datenstrukturen selbst ändert sich nicht dadurch, dass sie funktional sind. Dies ist jedoch bei Parallelität nicht der Fall:

1. Es gibt viele Modelle für verteilte / parallele / gleichzeitige Berechnungen.

2. Es gibt keine allgemeine Transformation, bei der Sie anhand der Spezifikation einer sequentiellen Datenstruktur die Spezifikation ihrer gleichzeitigen Version erhalten. Es gibt verschiedene Bedingungen (im Allgemeinen unter Sicherheits- und Lebendigkeitsbedingungen kategorisiert ), die wir von einer gleichzeitigen Version einer Datenstruktur verlangen können. Es gibt verschiedene neue Ergebnisse (z. B. Anhalten von Vorgängen, Abbrechen von Vorgängen, Abstürze usw.). Es kann also viele verschiedene Spezifikationen für gleichzeitige Versionen einer sequentiellen Datenstruktur geben.

Einige Fragen zu Referenzen zum verteilten Rechnen:

• Lernen Sie die Theorie verteilter Systeme kennen?
• Modernes verteiltes Computerbuch
• Bücher: Distributed Computing

Siehe auch Warum konnten wir keine einheitliche Komplexitätstheorie des verteilten Rechnens entwickeln?

Die erste Regel für gleichzeitige Datenstrukturen lautet: Sie möchten keine Parallelität.

Im Idealfall bedeutet verteiltes / paralleles / gleichzeitiges Rechnen, dass Sie über eine Reihe völlig unabhängiger sequentieller Prozesse verfügen. Jeder Prozess hat seine eigenen Daten und Ressourcen, und der Prozess kennt nicht einmal andere Prozesse.

Im schlimmsten Fall haben Sie ein Shared-Memory-System mit mehreren Threads, die dieselben Datenstrukturen gleichzeitig abfragen und aktualisieren. Wahrscheinlich ist etwas schrecklich schief gelaufen, wenn Sie ernsthaft darüber nachdenken.

Wenn es sich um gleichzeitige Datenstrukturen handelt, ist natürlich ein gewisses Maß an Parallelität unvermeidbar. Wir wollen es immer noch minimieren. Je länger ein Prozess nacheinander ablaufen kann, ohne Mutexe zu berühren, atomare Operationen auszuführen oder Nachrichten zu übergeben, desto wahrscheinlicher funktioniert alles korrekt und die Leistung ist akzeptabel.

Statische Datenstrukturen mit Stapelaktualisierungen erfordern weniger Synchronisation als dynamische Datenstrukturen. Sie sollten versuchen, Ihre gleichzeitigen Datenstrukturen statisch oder zumindest so statisch wie möglich zu gestalten. Wenn Ihr Algorithmus das Verschachteln von Abfragen mit Aktualisierungen erfordert, versuchen Sie, den Algorithmus zu ändern, bevor Sie auf gemeinsam genutzte dynamische Strukturen zurückgreifen.

Das gleiche Entwurfsprinzip gilt auch für die Aktualisierung statischer Datenstrukturen. Je unabhängiger Sie die Prozesse zur Aktualisierung der Struktur gestalten können, desto besser funktioniert alles.