Nebenläufigkeit, Parallelität, Asynchronität, Non-Blocking und ihre Konzepte

Ich habe mit einer einfachen Begriffsklärung begonnen und das Thema dann breit bis hin zu Grafik und Halbleitern behandelt.

1. Begriffe
   • Nebenläufigkeit / Parallelität
   • Asynchronität / Non-Blocking
   • präemptiv / nicht-präemptiv
2. Betriebssysteme und Prozessoren
   • Betriebssysteme
   • Prozessoren
3. Coroutines und Fibers
   • Fibers
   • Coroutines
4. Generatoren, Async/Await, Continuations
   • Generatoren
   • Async / Await
   • Continuations
5. Promise und Future
6. I/O-Multiplexing
   • Multiplexing
   • Sockets
   • I/O-Modelle
7. Ringpuffer, moderne I/O-Modelle, LMAX Disruptor
   • Ringpuffer
   • moderne I/O-Modelle
   • LMAX Disruptor
8. Synchronisationsprimitive
   • Notwendigkeit
   • Thread-Sicherheit
   • Spinlock
   • Mutex
   • Semaphor
   • STM
   • GIL
9. Ansätze anderer Skriptsprachen und Reactor-/Proactor-Pattern
   • Ractor (Ruby)
   • Node.js (Reactor-Pattern)
   • Proactor-Pattern
10. CSP und Akteure
    • CSP
    • Akteure
11. Green Threads, Goroutinen und moderne asynchrone Runtime-Technologien
    • Green Threads
    • moderne CSP-Runtimes
    • moderne Actor-Runtimes
12. Parallelität
    • SIMD und Pipelining
    • OpenMP & MPI
    • moderne Parallelisierungstechniken
    • Lambda-Architektur
13. GPU
    • Pipeline und Shader
    • Monitore
    • Buffering
    • vertikale Synchronisation
    • Frame Pacing und Beam Racing
    • Compositor
    • Grafik-API / Bibliotheken
14. Sonstige Chips
    • Überblick
    • DSP
    • FPGA
    • TPU
15. Referenzen

[roxie]

Bei Synchronizität und Asynchronität geht es darum, wer den Abschluss einer Aufgabe überprüft
Bei Blocking und Non-Blocking darum, ob es Kontrollhoheit gibt

Diesen Satz sehe ich in zahllosen Blogs immer wieder wortgleich wiederholt; mich würde interessieren, wo die ursprüngliche Quelle ist.

Die meisten Blogs sind zu beschäftigt damit, sich gegenseitig zu referenzieren, sodass ich den Originaltext nicht herausfinden konnte. Das Einzige, was ich halbwegs gefunden habe, ist das AIO-Dokument von IBM, aber ich habe den Eindruck, dass dort nur auf Kernel-I/O bezogen darüber gesprochen wird. Und ich habe auch gehört, dass selbst diese Unterscheidung umstritten ist.

Ist das ein maßgeblicher, vertrauenswürdiger Beurteilungsmaßstab?

[alstjr7375]

Zunächst scheint es sinnvoll zu sein, Synchron/Asynchron ausgehend von der Schaltungstechnik zu betrachten.
Synchrone Schaltungen verwenden einen Takt für das Timing, asynchrone werden durch Ereignisse oder andere Eingaben ausgelöst.
Das heißt, es dürfte nicht unpassend sein, eine asynchrone API ebenfalls als einen Mechanismus zu definieren, der auf die gleiche Weise durch Callbacks usw. ausgelöst wird.
https://developer.mozilla.org/en-US/docs/…

Bei Blocking-/Non-Blocking-APIs ist als Definition passend, ob man auf den Abschluss der Arbeit zwingend warten muss oder nicht.
Allerdings scheint diese Erklärungstendenz auch daher zu kommen, dass es für das Nicht-Warten eine Implementierung geben muss, bei der die aufgerufene Funktion die Kontrolle behält.
https://nodejs.org/en/docs/guides/blocking-vs-non-blocking/

Ich hatte das der Kürze halber ausgelassen, werde aber versuchen, diesen Inhalt zusätzlich aufzunehmen.

[roxie]

Ich stimme allen Ihren Ausführungen zu. Dennoch fällt es mir weiterhin schwer, Sicherheit darüber zu gewinnen, ob man diese beiden Achsen als Quadranten in einer Ebene darstellen sollte, ob man sie überhaupt so darstellen kann und ob sie sich dabei angemessen voneinander abgrenzen lassen. Für mich teilen Blocking und Sync konzeptionell zu 90 % denselben Kontext. Gleiches gilt für Non-Blocking & Async.

[alstjr7375]

Blocking-Sync und Non-Blocking-Async werden zwar oft zusammen verwendet, aber es gibt Fälle, in denen eine Unterscheidung nötig ist.

• Blocking-Async: I/O-Multiplexing wie select
• Non-Blocking-Sync: Daten-Polling

Deshalb denke ich eher, dass es richtig ist, sie getrennt zu unterscheiden und zu verwenden.

[roxie]

Ich glaube, ich kann Ihren genannten Beispielen kaum folgen, deshalb fällt es mir schwer, dem stärker zuzustimmen.

https://incredible-larva.tistory.com/entry/IO-Multiplexing-Topabogi-1bu In diesem Artikel wird es wie folgt erklärt:

Letztlich schaut sich der User-Process, der select angefordert hat, den zurückgegebenen Wert an und entscheidet daran, ob nachfolgende Arbeit anfällt. Weil mehrere unvorhersehbar eingehende I/O-Anfragen auf einmal verwaltet werden, wird das teils als asynchron angesehen; letztlich zeigt die tatsächliche einzelne I/O-Operation selbst aber ein synchrones Verhalten.

Mich würde interessieren, welche Meinung Sie dazu haben. Ehrlich gesagt hatte ich an diesem Punkt das Gefühl, dass diese 2x2-Klassifikation keinen Sinn mehr ergibt. Je nach Domäne und Perspektive scheinen die Interpretationen sehr auseinanderzugehen.

[alstjr7375]

Im Weiteren sieht man, dass beim Warten auf die Antwort des Kernels ein Callback-Signal vom Kernel kommt, dass der Ergebniswert vorbereitet ist, und der User-Prozess die Daten in seinen eigenen Buffer kopiert.

Da dieser Teil durch die oben erwähnte, per Callback ausgelöste Trigger-Methode funktioniert, wäre es, wenn man es unbedingt unterscheiden bzw. definieren müsste, wohl korrekt, dies als Blocking-Async zu bezeichnen.
Je nach Perspektive kann es Fälle geben, die etwas mehrdeutig wirken.

Polling ist allerdings ein eindeutiges Beispiel:
https://en.wikipedia.org/wiki/Polling_(computer_science)

Beim Polling wird wiederholt geprüft, ob die Daten bereit sind, daher ist es ein passendes Beispiel für Sync-Blocking.

[wonkwh]

Wow, vielen Dank für das tolle Material.

[kayws426]

Sehr interessant zu lesen!

[bus710]

Das Scrollen scheint endlos zu sein, haha.
Ein Buch mit dem Titel "7 Concurrency Models" behandelt ein ähnliches Thema und ist wohl durchaus einmal lesenswert.

[alstjr7375]

Wenn man das Inhaltsverzeichnis vergleicht, wirkt es ähnlich.
Scheint ein gutes Buch zu sein.