diff --git a/MPP2-EXPANSION/README.md b/MPP2-EXPANSION/README.md index 0069334..a6ef552 100644 --- a/MPP2-EXPANSION/README.md +++ b/MPP2-EXPANSION/README.md @@ -33,424 +33,320 @@ Als größtenteil irrelevant betrachtete Themen: # Hardwarenahe Programmierung -> **ToDo** -> - Application Binary Interface (ABI) [DONE] -> - C und Make siehe Kusche Entwicklerwerkzeuge -> - Register [DONE] -> - Stack [DONE] -> - Heap (relevant, aber in dem Modul nicht angesprochen) [DONE] -> - Grimm -> - Flags [DONE] -> - Timer [DONE] -> - Watchdog [DONE] -> - Interrupt [DONE] - - - ## Application Binary Interface (ABI) -- allgemein: Schnittstelle auf Maschinenebene (vgl. compilierte API) -- definierte Schnittstelle, die Assembler-Verarbeitung ermöglicht (vgl. Inline-Assembler) -- ermöglicht direkten Aufruf von Assembler-Routinen +- **Binärschnittstelle** zur Verarbeitung von Befehlen auf Maschinenebenen +- legt u.a. **Aufrufkonventionen** fest +- reserviert benötigte Prozessorregister +- muss auf eine Architektur festgelegt sein ## Register -- Datenregister zur Speicherung von Operanden und Ergebnisse -- Adressregister zur Adressierung von Operanden (Speichern von Adressen) -- Steuerregister +> Speicherbereich innerhalb eines Prozessors -## Stack (Speicher) +- **Datenregister:** Speicherung von Operanden und Ergebnisse +- **Adressregister:** Adressierung von Operanden (Speichern von Adressen) +- **Spezialregister:** Statusregister, Befehlszähler, Interrupt-Steuerregister, ... -- vgl Datenstruktur. Stapelspeicher, Kellerspeicher (push,pop), LIFO -- In Mikroprozessoren: Register Stackpointer - - bei Aufruf eines Unterprogramms: Rücksprungadresse ablegen - - Parameter und lokale Variablen leben im Stack (vgl. Pufferüberlauf) - - beginnt i.d.R. bei hoher Adresse, wächst Richtung 0 "nach unten" +## Stack(-Speicher) -## Heap (Speicher) +- vgl. Datenstruktur (Stapel-/Kellerspeicher $\rightarrow$ **LIFO**) +- beinhaltet **Parameter und lokale Variablen** +- in Mikroprozessoren: **Register des Stackpointer** +- bei Aufruf eines Unterprogramms: **Rücksprungadresse ablegen** +- beginnt i.d.R. bei hoher Adresse, wächst Richtung 0 "nach unten" +- bei **Multitasking-Systemen** besitzt **jeder Thread eine eigenen Stack** -- beliebig frei zuordnenbarer Speicherbereich -- in C: vgl. Objekte `malloc()` und co., `free()` -- ! nicht zu verwechseln mit Datenstruktur Heap +## Heap(-Speicher) + +- dynamischer Speicherbereich +- kann zur Laufzeit beliebig angefordert werden +- vgl. `malloc()`/`free()` in `C` +- im Gegensatz zu Stack deutlich größer ## AVR ATmega 8515L ### Flags -- Statusregister SREG enthält 1-Bit-Informationen (Flags) -- Zeigen Ereignisse an - - Carry - - Zero - - Negative - - Overflow - - Interrupt - - ... +- Statusregister `SREG` enthält **1-Bit-Informationen** (Flags) +- zeigen **Zustände** an `Carry`, `Zero`, `Negative`, `Overflow` +- Grundlage für **bedingte Sprünge** +- Auch zum **(De-)aktivieren** von Funktionen (`Interrupt`-Flag) ### Timer -- Zusammenhang MicroController-Takt -- i.d.R. Teilung des Takt (Prescaler) -- Anwendungen: - - periodische Interrupts als Zeitgeber - - Zeitverzögerungen; Ersatz für Programmschleifen - - Frequenzgenerator / -messer -- periodische Interrupts als Zeitgeber +- **Interrupt-Quelle** im Zusammenhang mit Microcontroller-Takt +- meist Teilung des Takt durch **Prescaler** + +**Anwendungen** + +- Zeitgeber (periodische Interrupts) +- Zeitverzögerungen (Ersatz für Programmschleifen) +- Frequenzgenerator/-messer ### Watchdog -- häufigste Anwendung: Reset des Programms im Fehlerfall -- eigener Takt -- zählt hoch -- Erreichen Schwellwert führt zu Neustart -- Im Normalbetrieb Reset der gezählten Zyklen -> kein Neustart -- Brownout Detection (Erkennen, ob die Betriebsspannung einen bestimmten Wert unterschreitet) - - tritt regelmäßig auf! $\rightarrow$ ohne Detection unvorhersehbares Verhalten +- Zähler mit eigenem Takt +- Erreichen eines **Schwellwert** führt zu Neustart +- Ziel: **Reset** des Programms im Fehlerfall (Endlosschleifen) +- wird im Normalbetrieb regelmäßig zurückgesetzt ### Interrupt -- Anforderung zur Unterbrechung des aktuellen Programms durch definiertes Ereignis -- Interruptflag gesetzt - - Program Counter (PC) automatisch auf Stack gspeichert, Statusregister manuell sichern! -- Behandlung des Interrupts: PC ruft Interrupt Service Routine (ISR) definiert in Interruptvektortabelle auf -- ... -- Mit PC vom Stack fortfahren +> **kurzfristige Unterbrechung** eines Programms durch eine von der CPU abzuarbeitende Befehlssequenz (Interrupt Service Routine $\rightarrow$ schnelle Reaktion auf I/O, Zeitgeber, ...) + +#### Ablauf eines Interrupt + +- Sperren weiterer Unterbrechungen mit gleicher oder geringerer Priorität +- Sicherung wichtiger Register-Informationen +- Bestimmen der Interruptquelle (durch Hardware realisiert) +- Laden des zugehörigen Interruptvektors +- Abarbeitung der Interruptroutine +- Rückkehr zur unterbrochenen Aufgabe (Registerinformationen wiederherstellen) # Systemprogrammierung -> **ToDo** -> -> - Parallele Programmierung -> - Kritischer Abschnitt [DONE] -> - Atomare Operation -> - Exklusive Ressource -> - Fork [DONE] -> - Deadlock [DONE] -> - Semaphore [DONE] -> - Interprozesskommunikation [DONE] -> - Pipes (uni/bidirektional, named) [DONE] -> - Sockets (lokal, rechnerübergreifend) [DONE] -> - Shared Memory [**ToDO**] -> - Signale?! +## Parallele Programmierung - - +> gleichzeitige Abarbeitung von Aufgaben -## Wie lautet das Philosophenproblem? +- Motivation: **Zeit sparen** $\rightarrow$ eine große Aufgabe wird zur selben Zeit in mehreren kleinen Teilen erledigt +- **Ausnutzung der Hardware:** Multicore-Prozessoren, verteilte Rechnerkerne -- 5 Philosophen mit 5 Stäbchen an rundem Tisch -- Aktion: Denken oder Essen; -- Essen benötigt zwei Stäbchen (Nicht genug Ressourcen für alle) -- gleichzeitiger Zugriff -- Deadlock kann entstehen +## Atomare Operation -## Was ist ein Deadlock? +- Verbund von Einzeloperationen, der als logische Einheit betrachtet wird +- kann nur als Ganzes erfolgreich ablaufen oder fehlschlagen +- nicht durch andere Operationen unterbrechbar -- **Allgemein** - - Situation, in der sich beide Alternativen eines Dilemmas gegenseitig blockieren **oder** - - in der die Handlungspartner nicht zu Kompromissen zur Lösung einer solchen Situation bereit sind, wodurch die Situation ausweglos wird. -- **Informatik** - - Gegenseitige Blockade mehrere Prozesse, weil sie auf die Freigabe von Betriebsmitteln warten, die ein anderer beteiligter Prozess bereits exklusiv belegt hat +## Exklusive Ressourcen -## Wie werden Deadlocks verhindert oder aufgelöst? +- Betriebsmittel, die zu jeden Zeitpunkt nur von genau einem Prozess genutzt werden können -- ggf. auch über Pipes (Implementierung notwendig) -- Sockets benutzen -- Semaphoren -- Reboot -- Auf Ressource verzichten (Signale an Prozess senden) -- Prozess beenden, Signal SIGTERM/SIGKILL +## Prozesssynchronisation - +> Koordinierung des zeitlichen Ablaufs mehrerer nebenläufiger Prozesse - +## Race Condition -## Zweck, Wirkweise fork() +> Konstellation, in der das Ergebnis einer Operation vom zeitlichen Verhalten bestimmter Einzeloperationen oder der Umgebung abhängt -- es wird eine exakte Kopie des Aufrufers als Kindprozess erzeugt -- Kindprozess übernimmt Code, Daten inkl. Befehlszähler, Dateideskriptoren, ... +## Deadlock + +- **Allgemein:** Situation, in der sich beide Alternativen eines Dilemmas gegenseitig blockieren +- **Informatik:** zyklische **Wartesituation** zwischen mehreren Prozessen, wobei jeder beteiligte Prozess auf die **Freigabe von Betriebsmitteln** wartet, die bereits ein **anderer beteiligter Prozess exklusiv belegt** hat + +### Philosophenproblem + +- **5 Philosophen** mit **5 Stäbchen** an rundem Tisch +- Aktion: Denken oder Essen +- Essen benötigt zwei Stäbchen +- wenn nur ein Stäbchen verfügbar ist, wird dieses so lange reserviert, bis auch das zweite verfügbar ist. + +> gleichzeitiger Zugriff $\rightarrow$ Deadlock + +### Vermeidung von Deadlocks + +> eine der notwendigen Bedingungen eliminieren + +- **Exklusive Ressourcen:** Verwaltung durch Spooler +- **Belegungs- und Wartebedingung:** alle benötigten Ressourcen im vorraus anfordert und nur dann ausführen, wenn alle verfügbar +- **Ununterbrechbarkeit:** Prozessen Ressourcen entziehen (oft schwierig/unmöglich $\rightarrow$ Drucker) +- **Zyklische Wartebedingung:** Ressourcen durchnummerieren und nur in aufsteigender Reihenfolge reservieren + +#### "Hartes" Beenden eines Deadlock-Zustandes + +- Prozess beenden, Signal `SIGTERM`/`SIGKILL` +- Reboot - +## fork() -## Rückgabewerte fork +- erzeugt exakte Kopie des Aufrufers als Kindprozess +- Kindprozess übernimmt Code, Daten inkl. Befehlszähler, Dateideskriptoren, ... + +### Rückgabewerte von fork() - `>0`: die PID des Kindprozesses - `0`: es wurde eben geforkt und wir sind das Kind - `-1`: Fehler - +## Semaphore -## Motivation Interprozesskommunikation +- Variable, die die **Verwaltung beschränkter (zählbarer) Ressourcen** ermöglicht +- Manipulation der Semaphore über zwei **unteilbare Operationen** (reservieren = `P(sema)`; freigeben = `V(sema)`) +- **Synchronisation** von Prozessen $\rightarrow$ Semaphore **realisiert ein passives Warten der Prozesse** -- Verhinderung von - - gleichzeitigen Schreibzugriffen - - Verhungern von Prozessen - - Deadlocks - -### Wie können Sie bidirektionale Interprozesskommunikation ermöglichen? +## Kritische Abschnitt -- Pipe umdrehen, ggf. mit Zugriffskonzept (Semaphore), BAD Practice -- 2 Pipes verwenden -- Sockets +> mehreren Einzelanweisungen, deren Zwischenergebnisse inkonsistente Zustände darstellen - +- zu jedem Zeitpunkt darf sich nur ein einziger Prozess in diesem Abschnitt aufhalten (Sicherstellung der Konsistenz, Deadlocks) +- Entwickler definieren einen kritischen Abschnitt -## Was sind Semaphoren und wozu werden Sie eingesetzt? +## Interprozesskommunikation -- Mittel der Interprozesskommunikation zur Verwaltung von (exklusivem) Zugriff auf Ressourcen -- Deadlock vermeiden +> Informationsaustausch zwischen mehreren Prozessen -## Was ist der kritische Abschnitt im Kontext Sempahoren? +- Mittel: Pipes, Sockets, Shared Memory +- Ziel: Verhinderung von... + - gleichzeitigen Schreibzugriffen + - Verhungern von Prozessen + - Deadlocks -- Es ist ein Codebereich, der nur in einer definierten Anzahl von Prozessen gleichzeitig zur Verfügung steht (stehen sollte) -- Entwickler müssen im Programm dafür Sorge tragen und den kritischen Abschnitt definieren -- Semaphor Operation P, Passieren, Vor dem kritischen Abschnitt LOCK - Ressourcen blockieren -- Semaphor Operation V, Verlassen, Nach dem kritischen Abschnitt UNLOCK - Ressourcen freigeben +### Pipes - +- **unidirektionaler Datenstrom zwischen zwei Prozessen** +- vgl. Puffer/Warteschlange nach dem **FIFO**-Prinzip -## Was sind Pipes im Kontext Interprozesskommunikation? Unterscheiden Sie zwei Arten von Pipes +#### Pipes: Arten -- unidirektionaler Datenstrom zwischen zwei Prozessen: Puffer/Warteschlange nach dem FIFO-Prinzip -- namenlose Pipes: Kommunikation zwischen verwandten Prozessen (vgl. fork()) -- benannte Pipes: Zugriff durch alle Prozesse mit Zugriffsrecht möglich +- **namenlose Pipes:** Kommunikation zwischen Prozessen mit gemeinsamen Vorfahren (`fork()`) +- **benannte Pipes:** Zugriff durch alle Prozesse mit Zugriffsrecht möglich -## Welche Operationen auf einer Pipe kennen Sie? Beschreiben Sie deren Funktion +#### Pipes: Operationen - `write(pipefd[1],buffer)` - - Write: Aus Programmbuffer auf die Pipe schreiben, in den Kernelbuffer - - Daten sind gepuffert bis sie gelesen werden + - Write: aus **Programmbuffer auf die Pipe schreiben** (in den Kernelbuffer) + - Daten sind **gepuffert bis sie gelesen werden** - `read(pipefd[0],buffer)` - - Read: Aus Kernelbuffer in Programmbuffer schreiben; aus Sicht des Programms von Pipe lesen - - Lesen verbraucht Daten der Pipe + - Read: aus **Kernelbuffer in Programmbuffer schreiben** ("Pipe lesen") + - Lesen verbraucht Daten der Pipe (vgl. Warteschlange) - +### Socket -## Addressfamilien Socket +#### Socket: Addressfamilien -- POSIX local inter-process communication sockets/Unix Domain Socket/IPC Socket (AF_UNIX,AF_LOCAL) -- Internet-Domain (AF_INET und AF_INET6) +- `AF_UNIX`: Unix-Domain +- `AF_INET`: Internet-Domain (bzw. `AF_INET6`) - diverse andere, viele veraltet - - AF_IRDA - - AF_BLUETOOTH + - `AF_IRDA` + - `AF_BLUETOOTH` -## Arten Socket +#### Socket: Arten -- Verbindungslos (SOCK_DGRAM) -- vollduplex, verbindungsorientiert (SOCK_STREAM) +- `SOCK_DGRAM`: verbindungslos (vgl. `UDP`) +- `SOCK_STREAM`: verbindungsorientiert (vgl. `TCP`) außerdem -- SOCK_RAW nur für Developer, Root-User, Zugriff auf L3,L2-Felder --> eigenes L4-Protokoll entwickeln -- SOCK_SEQPACKET (nur UNIX, besseres SOCK_STREAM) +- `SOCK_RAW`: nur für Developer, Root-User, Zugriff auf L3,L2-Felder $\rightarrow$ eigenes L4-Protokoll entwickeln -## Unterschied Pipe Socket +### Pipe vs. Socket -- Pipes - - Unix-Domaine exklusiv, d.h. gleiches Rechensystem - - unidirektional -- Socket - - Unix/Internetdomäne - - bidirektional +| Pipes | Sockets | +| --------------------------------------------------------------------- | --------------------- | +| - unidirektional | - bidirektional | +| - Unix-Domaine (nur gleiches Rechensystem) | - Unix/Internetdomäne | +| - Kommunikationspartner benötigen gemeinsamen Elternprozess (unnamed) | | -# Entwicklung von Webanwendungen +### Shared Memory -> **ToDo** -> -> - HTML [DONE 90%] -> - CSS [DONE?] -> - Selektoren [DONE] -> - Javascript -> - PHP +- **geteilter Speicherbereich** zwischen mehreren Prozessen +- Kommunikation über Shared Memory erfordert **Prozesssynchronisation** - - -## Geschichte des Internets +### bidirektionale Interprozesskommunikation - +- zwei Pipes (für jede Richtung eine) +- Sockets +- Shared Memory -- 1958: Gründung Advanced Research Projects Agency -- 1969: ARPAnet vernetzt 4 Großrechner in Kalifornien und Utah -- 1972: 37 Einrichtungen in USA angeschlossen -- 1974: Entwicklung TCP, später TCP/IP -- 1986: Top Level Domains werden ins Leben gerufen -- 1989: Timothy Berners-Lee entwickelt ersten "Browser" WorldWideWeb -- 1991: Berners-Lee veröffentlicht HTML sowie die erste WWW-Seite -- 1992: 1 Mio. Rechner im Internet -- 2001: Wikipedia geht online -- 2005: Youtube geht ins Netz - - $\rightarrow$ erstmals von Web 2.0 gesprochen (Inhalte kommen primär von den Nutzern) +# Entwicklung von Webanwendungen ## Client-Technologien -- HTML 5 $\rightarrow$ Beschreibung der Struktur der Webseiten -- CSS 3 $\rightarrow$ Formatierung / Aussehen -- Java-/ECMA-Script $\rightarrow$ Interaktion -- DOM/Ajax $\rightarrow$ Manipulation des Seiteninhalts -- Flash $\rightarrow$ obsolet -- JSON, XML(SVG, MathML, RSS, GraphML, ...) $\rightarrow$ Datenaustausch +- `HTML 5` $\rightarrow$ Beschreibung der Struktur der Webseiten +- `CSS 3` $\rightarrow$ Formatierung / Aussehen +- `Java-/ECMA-Script` $\rightarrow$ Interaktion +- `DOM/Ajax` $\rightarrow$ Manipulation des Seiteninhalts +- `JSON`, `XML`(`SVG`, `MathML`, `RSS`, `GraphML`, ...) $\rightarrow$ Datenaustausch ## Server-Technologien -- PHP -- NodeJS -- Ruby (on Rails) -- Java -- ASP.NET -- ColdFusion +- `PHP` +- `Java` +- `NodeJS` +- `Ruby` *(on Rails)* +- `ASP.NET` ## HTML ### HTML-Sytnax: Tags -- Auszeichnung von Textelementen durch Tags +- Auszeichnung von Elementen durch Tags - `Text` -- Öffnendes Tag schließendes Tag dazwischen Body - schließende Tags können in einigen Fällen entfallen (z.B. ``) -- Tags können Attribute enthalten `body` +- Tags können **Attribute** enthalten `body` +- Tags können **hierarchisch** geschachtelt werden -### HTML Struktur: `` +### HTML-Struktur: `` - `` ist sogenanntes Wurzeltag -- Attribut "lang" gibt die Dokumentensprache an - -### HTML Struktur: `` - -- Dateikopf, Metainformationen, keine Darstellungen -- Informationen werden durch Browser, Suchmaschinen und Crawler benutzt - -### Beispielelemente in `` - -```html - - - - - - - - - Hier steht der Titel der Seite - - - - - - - Titel - -``` +- Attribut `lang` gibt die Dokumentensprache an -### HTML Struktur: `` +### HTML-Struktur: `` -Hauptteil der Seite, Inhalt, angezeigte Elemente +- **Dateikopf**, **Meta**informationen, **keine Darstellungen** +- Informationen werden durch **Browser**, **Suchmaschinen** und **Crawler** benutzt -### HTML Hyperlinks - -- `a` $\rightarrow$ anchor aka Hyperlinks -- `href="dokument.html"` ODER `="#ziel"` ODER `="dokument#ziel"` -- `href=""` $\rightarrow$ Seite neuladen -- `href="#"` oder `href="#top"` $\rightarrow$ Seitenanfang -- `download` $\rightarrow$ bei href angegebene Datei soll heruntergeladen werden -- `target` $\rightarrow$ wo Linkziel öffnen - -### HTML Tabellen - -```html - - - - - - -``` +### HTML-Struktur: `` -- input type: - - `text` - - `password` - - `color` - - `checkbox` - - `date` - - `file` - - `number` - - `radio` - - `range` - -### HTML Listentypen - -- sortiert $\rightarrow$ `ol` > `li` -- unsortiert $\rightarrow$ `ul` > `li` -- Beschreibungsliste $\rightarrow$ `dl` > `dt`, `dd` +- Hauptteil der Seite +- Inhalt (angezeigte Elemente) ### HTML 5: Verbesserungen -- Schwerpunkt auf Gliederung der Seite $\rightarrow$ bessere Übersicht bei vielen Elementen -- Suchmaschinen werten den Inhalt der Seite besser aus (mehr Semantik in der Syntax) +- Schwerpunkt auf **semantischer Gliederung** der Seite +- bessere **automatisierte Auswertung** der Inhalte durch **Suchmaschinen** - Screenreader können flüssiger lesen - weitere Neuerungen für Multimedia, Formulare -### HTML 5 Gliederungselemente +#### HTML 5: Gliederungselemente -- ``
`` -- ``