Flashcards
Kommunikationsmodelle 3 & Programmierparadigmen

Cards in this deck (127)
- 1Wissensbasierte Modelle (Transaktionaler Speicher) (Benutzung von Semaphoren) (Die Idee) (Dummerweise)- Kommunikation mittels gemeinsamen Speicher zwar sehr schnell
- klassische Synchronisation über wechselseitigen Ausschluss (Semaphore, Monitore) jedoch stark Parallelität limiterend - 2Wissensbasierte Modelle (Transaktionaler Speicher) (Benutzung von Semaphoren) (Die Idee) (Gesucht)- alternatives Synchronisationsparadigma
- 3Wissensbasierte Modelle (Transaktionaler Speicher) (Benutzung von Semaphoren) (Die Idee) (Transaktionaler Speicher)- Kommunikation mittels gemeinsamen Speicher
- Synchronisationskonzept transaktionaler Systeme - 4Wissensbasierte Modelle (Transaktionaler Speicher) (Programmierparadigma)

- 5Wissensbasierte Modelle (Transaktionaler Speicher) (Programmierparadigma) (Paradigmen zur Synchronisation in parallelen Systemen mit gemeinsamen Speicher) (Semaphore, Leases, (Hoare'sche) Monitore)=> Jobs der Programmierer:
- Identifikation kritischer Abschnitte
- Korrektheit, Verklemmung, Fairness, Grad der Parallelität,... - 6Wissensbasierte Modelle (Transaktionaler Speicher) (Programmierparadigma) (Paradigmen zur Synchronisation in parallelen Systemen mit gemeinsamen Speicher) (Transaktionaler Speicher (TM))=> Job der Programmierer:
- Identifikation kritischer Abschnitte
- TM-Paradigma erledigt den Rest - 7Wissensbasierte Modelle (Transaktionaler Speicher) (Programmierparadigma) (Ausflug: Definition einer Transaktion)

- 8Wissensbasierte Modelle (Transaktionaler Speicher) (Programmierparadigma) (Ausflug: ACID-Eigenschaften) ((acid = bissig, ätzend); Härder 1983) (Atomarität)- Atomarität (Atomicity): Eine Transaktion ist unteilbar
=> "alles oder nichts", auch unter Anwesenheit von Ausfällen - 9Wissensbasierte Modelle (Transaktionaler Speicher) (Programmierparadigma) (Ausflug: ACID-Eigenschaften) (Konsistenz)- Konsistenz (Consistency): Eine Transaktion überführt ein System aus einem konsistenten Zustand in den Nächsten
=> u.a. sind Teilergebnisse während der Ausführung einer Transaktion von außerhalb nicht beobachtbar - 10Wissensbasierte Modelle (Transaktionaler Speicher) (Programmierparadigma) (Ausflug: ACID-Eigenschaften) (Isolation)- Isolation oder Serialisierbarkeit (Serializability): Parallele Transaktionen beeinflussen sich gegenseitig nicht
=> Wirkung der äquivalent der (irgend)einer sequenziellen Ausführung - 11Wissensbasierte Modelle (Transaktionaler Speicher) (Programmierparadigma) (Ausflug: ACID-Eigenschaften) (Dauerhaftbarkeit)- Dauerhaftbarkeit (Durability): Die Wirkung einer Transaktion nach ihrem Abschluss ist permanent
=> ... auch unter Anwesenheit von Ausfällen - 12Wissensbasierte Modelle (Transaktionaler Speicher) (Programmierparadigma) (Transaktionale Zugriffssemantik) (ACI für Speicherobjekte)- Programmobjekte (Variablen, Klasseninstanzen, Listen, ...)
- Low-Level-Kommunikationsobjekte (Speicherseiten) - 13Wissensbasierte Modelle (Transaktionaler Speicher) (Programmierparadigma) (Transaktionale Zugriffssemantik) (Atomarität)- Unteilbarkeit von Gruppen (evtl. asynchroner) Operationen
- 14Wissensbasierte Modelle (Transaktionaler Speicher) (Programmierparadigma) (Transaktionale Zugriffssemantik) (Konsistenz)- Unbeobachtbarkeit von Zwischenergebnissen (z.B. partiell veränderte structs, inkonsistente Listenverzeigerung)
- 15Wissensbasierte Modelle (Transaktionaler Speicher) (Programmierparadigma) (Transaktionale Zugriffssemantik) (Isolation)- parallele Transaktionen beeinflussen sich gegenseitig nicht
- 16Wissensbasierte Modelle (Transaktionaler Speicher) (Programmierparadigma) (Transaktionale Zugriffssemantik) (Beispiel: TM in Java)

- 17Wissensbasierte Modelle (Transaktionaler Speicher) (Programmierparadigma) (Transaktionale Zugriffssemantik) (Beispiel: TM in Java) (Variante 1)

- 18Wissensbasierte Modelle (Transaktionaler Speicher) (Programmierparadigma) (Transaktionale Zugriffssemantik) (Beispiel: TM in Java) (Variante 2)

- 19Wissensbasierte Modelle (Transaktionaler Speicher) (Programmierparadigma) (Wechselseitiger Ausschluss vs. Transaktionen) (Semantik von Transaktionen: beobachtbare Wirkung)

- 20Wissensbasierte Modelle (Transaktionaler Speicher) (Programmierparadigma) (Qunitessenz) (Kommunikation und Synchronisation in parallelen Algorithmen) (Performanz)- Kommunikation über gemeinsamen Speicher
- Sperren arme Synchronisation erhöht Grad der Prallelität - 21Wissensbasierte Modelle (Transaktionaler Speicher) (Programmierparadigma) (Qunitessenz) (Kommunikation und Synchronisation in parallelen Algorithmen) (Korrektheit und Lebendigkeit)- Automatisierung der Synchronisation vermeidet Synchronisationsfehler
=> Programmierparadigma mit kräftigen Erleichterungen für Programmierer paralleler Algorithmen - 22Wissensbasierte Modelle (Transaktionaler Speicher) (Programmierparadigma) (Qunitessenz) (Rollenmodell)- Ausführer von Gruppen synchroner oder asynchroner Operationen
-> atomar
-> isoliert (ungestört) - 23Wissensbasierte Modelle (Transaktionaler Speicher) (Programmierparadigma) (Qunitessenz) (Datenmodell)Speicherobjekte; typisch
- BS-Ebene
-> Cache Lines
-> Seiten
- Anwendungsebene
-> Programmvariablen - 24https://i.gyazo.com/6d32d9b88d7a2f03dbfe94f4b48f34dd.pngWissensbasierte Modelle (Transaktionaler Speicher) (Programmierparadigma) (Messages) (TM: alternatives Paradigma zur Koordination von Parallelität)-

- 25Wissensbasierte Modelle (Transaktionaler Speicher) (Programmierparadigma) (Messages) (Stand der Kunst: frisch)

- 26Zusammenfassung (Problemorientierte Kommunikationsmodelle) (Modellkomponenten)

- 27Zusammenfassung (Betrachtete Modelle)- botschaftenbasierte Modelle
-> elementar, universell, zahlreiche Varianten
=> Teil der API vieler Betriebssysteme
=> Grundlage problemspezifischer Kommunikationsmodelle - 28Zusammenfassung (Betrachtete Modelle) (problemspezifische Modelle) (strombasierte Modelle)- strombasierte Modelle
-> multimediale Informations- und Kommunikationssysteme - 29Zusammenfassung (Betrachtete Modelle) (problemspezifische Modelle) (Blackboards)- Blackboards, ereignisbasierte Modelle
-> Workflow-Management-System, Börsenhandel, Cloud Computing - 30Zusammenfassung (Betrachtete Modelle) (problemspezifische Modelle) (auftragsorientierte Modelle)- auftragsorientierte Modelle
-> viele Internetanwendungen (Web, E-Mail, DNS), DBMSe - 31Zusammenfassung (Betrachtete Modelle) (problemspezifische Modelle) (funktionsaufrufbasierte Modelle)- funktionsaufrufbasierte Modelle
-> Finanz- und Versicherungswirtschaft, Telemetriesysteme (Raumfahrt), Telekommunikationssysteme, Produktionsanlagensteuerung - 32Zusammenfassung (Betrachtete Modelle) (problemspezifische Modelle)- Blackboards, ereignisbasierte Modelle
- auftragsorientierte Modelle
- funktionsaufrufbasierte Modelle
- strombasierte Modelle
- wissensbasierte Modelle
- transaktionaler Speicher - 33Zusammenfassung (Betrachtete Modelle) (problemspezifische Modelle) (wissensbasierte Modelle)- wissensbasierte Modelle
=> Ad-hoc-Dienstinfrastrukturen - 34Erinnerung: Die 7 Plagen verteilter Systeme (bei der Herstellung der Idealvorstellung des Fernaufrufs)

- 35Erinnerung: Ablauf eines RPCs

- 36RPC-Systeme (Vorherrschende RPC-Implementierungen - die Qual der Wahl) ("1. Gerneration": u.a.)- ONC RPC (vormals Sun RPC)
- XML-RPC
- Java RMI (Remote Methode Invocation) ("OO-RPC") - 37RPC-Systeme (Vorherrschende RPC-Implementierungen - die Qual der Wahl) ("2. Gerneration": u.a.)- Google gRPC
- Apache Thrift
- Twitter Finagle
- Cap'n Proto
- JSON-RPC - 38RPC-Systeme (ONC (Open Network Computing) RPC) (Überblick)- entwickelt für Client-Server-Kommunikation im Sun Network File System (NFS)
- 39RPC-Systeme (ONC (Open Network Computing) RPC) (Bezeichnung)- auch ONC (Open Network Computing) RPC
- 40RPC-Systeme (ONC (Open Network Computing) RPC) (basiert auf)- (Aufruf-)Konventionen, die für Unix-Systeme und die Sprache C üblich sind
- 41RPC-Systeme (ONC (Open Network Computing) RPC) (Implementierungen)- existieren für meiste UNIX-artige Systeme, auch für Linux
- 42RPC-Systeme (ONC (Open Network Computing) RPC) (Konfiguration)- Protokoll: UDP oder TCP
- Fehlersemantiken: at-least-once, at-most-once (unter Mitwirkung des Entwicklers)
- optional: Broadcast RPC - 43RPC-Systeme (ONC (Open Network Computing) RPC) (Überblick) (Spezifikationssprache RPCL (RPC Language)- Beschreibung von Stub-Prozeduren etc.
- Anlehnung an C-Syntax - 44RPC-Systeme (ONC (Open Network Computing) RPC) (Überblick) (Austauschformat XDR (External Data Representation)- architekturunabhängige Spezifikation und einheitliche Darstellung zu übertragender Daten
- 45RPC-Systeme (ONC (Open Network Computing) RPC) (Überblick) (Compiler rpcgen)- erzeugt C-Code
- 46RPC-Systeme (ONC (Open Network Computing) RPC) (Compiler rpcgen))erzeugt auf Basis einer Beschreibung in RPCL
1. Muster (Template) für einen RPC-Client
2. Client-Stub
3. Template für einen RPC-Server
4. Server-Stub
5. gemeinsames Header-File für beide Komponenten
6. Botschaften-Template für Datenaustausch (Sprache XDR)
7. Template eines Makefile für C-Compiler - 47RPC-Systeme (ONC (Open Network Computing) RPC) (Ein konkretes Schritt-für-Schritt-Beispiel) (Umwandlung einer lokalen Prozedur in einen Remote Procedure Call (RPC)) (Gegeben: eine einfache lokale Prozedur)

- 48RPC-Systeme (ONC (Open Network Computing) RPC) (Ein konkretes Schritt-für-Schritt-Beispiel) (Umwandlung einer lokalen Prozedur in einen Remote Procedure Call (RPC)) (Das C-Programm printmsg)

- 49RPC-Systeme (ONC (Open Network Computing) RPC) (Ein konkretes Schritt-für-Schritt-Beispiel) (Umwandlung einer lokalen Prozedur in einen Remote Procedure Call (RPC)) (Ausführung von printsmg (lokal))

- 50RPC-Systeme (ONC (Open Network Computing) RPC) (Ein konkretes Schritt-für-Schritt-Beispiel) (Wie nun Umsetzung als RPC? (1. Schritt: RPCL-Spezifikation)

- 51RPC-Systeme (ONC (Open Network Computing) RPC) (Ein konkretes Schritt-für-Schritt-Beispiel) (Wie nun Umsetzung als RPC? (2. Schritt: C-Implementierung der Remote-Prozedur)

- 52RPC-Systeme (ONC (Open Network Computing) RPC) (Ein konkretes Schritt-für-Schritt-Beispiel) (Wie nun Umsetzung als RPC? (2. Schritt: C-Implementierung der Remote-Prozedur) (Vergleich: printmessage_1 (remote) vs. printmessage (lokal)

- 53RPC-Systeme (ONC (Open Network Computing) RPC) (Ein konkretes Schritt-für-Schritt-Beispiel) (Wie nun Umsetzung als RPC? (3. Schritt: Client-Programm) (1)

- 54RPC-Systeme (ONC (Open Network Computing) RPC) (Ein konkretes Schritt-für-Schritt-Beispiel) (Wie nun Umsetzung als RPC? (3. Schritt: Client-Programm) (2)

- 55RPC-Systeme (ONC (Open Network Computing) RPC) (Ein konkretes Schritt-für-Schritt-Beispiel) (Wie nun Umsetzung als RPC? (3. Schritt: Client-Programm) (RPC-Bibliotheksroutinen)- clnt_create(): Client Handle erzeugen
-> Parameter "visible" legt fest, dass jedes in /etc/netconfig beschriebene Transportprotokoll verwendet werden kann
- clnt_destroy(): Client Handle löschen - 56RPC-Systeme (ONC (Open Network Computing) RPC) (Ein konkretes Schritt-für-Schritt-Beispiel) (Wie nun Umsetzung als RPC? (3. Schritt: Client-Programm) (Stub-Routine)- printmessage_1()
- 57RPC-Systeme (ONC (Open Network Computing) RPC) (Ein konkretes Schritt-für-Schritt-Beispiel) (Wie nun Umsetzung als RPC? (3. Schritt: Client-Programm) (Fehlermanagement)- clnt_pcreaterror(): Fehlerausgabe mit Hinweis, warum RPC handle nicht erzeugt werden konnte, erzeugen
- clnt_perror(): Fehlerausgabe mit Hinweis, warum RPC fehlgeschlagen ist, erzeugen - 58RPC-Systeme (ONC (Open Network Computing) RPC) (Ein konkretes Schritt-für-Schritt-Beispiel) (Kompilieren und Ausführen)

- 59RPC-Systeme (Typischer Workflow)

- 60RPC-Systeme (Synchrone RPCs vs. asynchrone RPCs)

- 61RPC-Systeme (Google gRPC) (Anwendungsfeld)- Microservices
- 62RPC-Systeme (Google gRPC) (Use Cases)- verteilte Applikationen (Data Centers, Public/Private Cloud)
- Client-Server-Kommunikation (Mobile, Web, Cloud, eingebettete Systeme, IoT)
- Zugriff auf Google Cloud Services (z.B. von GPC, Android-/iOS-Geräten) - 63RPC-Systeme (Google gRPC) (Prominente Anwender)- Square, Netflix, CoreOS (Container Linux), Cisco, ...
- 64RPC-Systeme (Google gRPC) (Sprachunterstützung, Kommunikationsprotokoll, Nachrichtenformat)

- 65RPC-Systeme (Google gRPC) (Typischer Entwicklungsablauf)- Spezifikation des Protobuf-Interfaces
- Anwendung des Protobuf-Compilers protoc: Generierung der Service
- Implementierung der Services im Server
- Instanziierung des Stubs im Server
- Testen, testen, testen, ... Done! - 66ProgrammierparadigmenProgrammierparadigmen
- 67Algorithemenparadigma- Allgemein: "Paradigma" [griechisch] das: Beispiel, Muster (Brockhaus)
- Informatik: "Muster" für Entwurf und Formulierung von Algorithmen - 68Applikativ- Verallgemeinerung der Funktionsauswertung
- 69Imperativ- basierend auf einem einfachen Maschinenmodell mit gespeicherten und änderbaren Werten
- 70Deduktiv- basierend auf logischen Aussagen und Schlussfolgerungen
- 71Applikative Algorithmen

- 72Applikative Algorithmen (Grundidee)- Definition zusammengesetzter Funktionen durch Terme:
f(x) = 5x +1 - 73Applikative Algorithmen (Unbestimmte)- x, y, z, .... vom Typ int
- q, p, r, .. vom Typ bool - 74Applikative Algorithmen (Terme mit Unbestimmten)

- 75Applikative Algorithmen (Funktionsdefinitionen)

- 76Applikative Algorithmen (Erweiterung der Funktionsdefinition)

- 77Applikative Algorithmen (applikativer Algorithmus)

- 78Kategorisieren der funktionalen Sprachen (Erste Ordnung)- Funktionen können (nur) definiert und aufgerufen werden
- 79Kategorisieren der funktionalen Sprachen (Höhere Ordnung)- Funktionen können außerdem als Parameter an Funktionen übergeben werden und/oder Ergebnisse von Funktionen sein
- Funktionen sind hier auch Werte! -- erstklassige Werte;
- Erstklassig: Es gibt keine Einschränkungen
- Umgekehrt: Wert ist eine Funktion ohne Parameter - 80Kategorisieren der funktionalen Sprachen (Auswertungsstrategie) (Strikte Auswertung)- Synonyme: strict evaluation, eager evaluation, call by value, applikative Reduktion
- Die Argumente einer Funktion werden vor Eintritt in die Funktion berechnet (ausgewertet) - wie z.B. in Pascal oder C - 81Kategorisieren der funktionalen Sprachen (Auswertungsstrategie) (Bedarfsauswertung)

- 82Kategorisieren der funktionalen Sprachen (Typisierung) (Stark typisiert)- Die verbreiteten funktionalen Programmiersprachen sind stark typisiert, d.h. alle Typfehler werden erkannt
-> Statisch typisiert: Typprüfung wird zur Übersetzungszeit ausgeführt
-> Dynamisch typisiert: Typprüfung wird zur Laufzeit ausgeführt - 83Kategorisieren der funktionalen Sprachen (Typisierung) (Untypisiert)- Reiner Lambda-Kalkül
- 84Unsere Welt und unser Handeln sind nebenläufig

- 85Nebenläufige Programmierung und Erlang

- 86Endliche Automaten (1)

- 87Endliche Automaten (2)

- 88Zusammenfassung Nebenläufigkeit

- 89Kalküle (Kalküle sind)- Minimalistische Programmiersprachen zur Beschreibung von Berechnungen
- Mathematische Objekte, über die Beweise geführt werden können - 90Der untypisierte λ-Kalkül

- 91Strukturelle Induktion

- 92Der untypisierte λ-Kalkül (λ-Terme)

- 93Der untypisierte λ-Kalkül (Variablenkonvention) (Abstraktion ist rechtassoziativ)

- 94Gründe für verteilte Programme

- 95Kommunikationsmodelle (Asynchrone Kommunikation)

- 96Kommunikationsmodelle (Synchrone Kommunikation)

- 97Vergleich (asynchron vs synchron)

- 98Aktormodell

- 99Aktormodell (Bild)

- 100RPC: Prinzip

- 101Fehlersemantik bei RPC (Umgang mit Timeouts, Serverausfall, etc...) (Maybe)- Keine Wiederholung des Prozeduraufrufs
- Keine Garantie für Ausführung - 102Fehlersemantik bei RPC (Umgang mit Timeouts, Serverausfall, etc...) (At-least-once)- Wiederholte Ausführung, aber keine Erkennung von Nachrichtenduplikaten
- Nur für idempotente Operationen (z.B. Lesen) - 103Fehlersemantik bei RPC (Umgang mit Timeouts, Serverausfall, etc...) (At-most-once)- Garantie, dass mehrfache Client-Aufrufe nicht zum mehrmaligen Prozeduraufruf führen, z.B. durch Sequenznummern der Nachrichten, Protokollierung -> Duplikateliminierung
- Für nicht-idempotente Operationen (z.B. Einfügen, Löschen) - 104Parallelprogrammierung (Einordnung)

- 105Parallelprogrammierung (Multiprozessorsysteme)

- 106Parallelprogrammierung Symmetrisch vs. Nicht-symmetrisch

- 107Parallelprogrammierung Flynn‘s Architekturklassifikation

- 108Parallelprogrammierung Maße zur Leistungsbewertung

- 109Parallelprogrammierung Amdahlsches Gesetz (1)

- 110Parallelprogrammierung Amdahlsches Gesetz (2)

- 111Parallelprogrammierung Parallelisierungsarten (Task-Parallelität)- Ausnutzung inhärenter Parallelität durch simultane Ausführung unabhängiger Aufgaben
- 112Parallelprogrammierung Parallelisierungsarten (Datenparallelität)- Gemeinsame Operation auf homogener Datenmenge
- Zerlegung eines Datensatzes in kleinere Abschnitte - 113Parallelprogrammierung (Taskparallelität)

- 114Parallelprogrammierung (Datenparallelität)

- 115Parallelprogrammierung Parallele Programmierung in Erlang

- 116Parallelprogrammierung Job und Task Tracker

- 117Parallelprogrammierung MapReduce: Fazit

- 118Parallelprogrammierung in JavaUnterstützt durch
-> Thread-Konzept
- eingebaute Mechanismen zur Synchronisation nebenläufiger Prozesse
- spezielle High-Level-Klassen im Packet java.util.concurrency - 119Parallelprogrammierung Threads

- 120Parallelprogrammierung Threads in Java

- 121Parallelprogrammierung (Threads) Wechselseitiger Ausschluss

- 122Parallelprogrammierung Tasks und Futures

- 123Parallelprogrammierung Zusammenfassung

- 124Generische Programmierung (Typ-Substituierbarkeit)

- 125Generische Programmierung Kovarianz und Kontravarianz

- 126Generische Programmierung (Kovarianz und Kontravarianz in Vererbungshierarchien)

- 127Generische Programmierung (Kovarianz und Kontravarianz) (In objektorientierten Programmiersprachen)- Kontravarianz: für Eingabeparameter
- Kovarianz: für Rückgabewerte und Ausnahmen
- Invarianz: für Ein- und Ausgabeparameter
Information
- Description
- Flashcards on Kommunikationsmodelle 3 & Programmierparadigmen, created by Julian Rottenberg on 04/07/2018.
- Created by
- Julian Rottenberg
- Views
- 42
- Tags
- Rating