KE 2

• von OS: ein Programm in Ausführung

• laufen nebeneinander, ohne sich zu stören

• wechsel zwischen Prozessen:

  • viel Aufwand

  • Register in MMU (memory management unit) ändern

  • address translation caches leeren in translation lookaside buffer (TLB)

• Prozess-Kontext

  = Einträge in Prozess-Tabelle

  • mit:

    • CPU register Werte

    • memory maps

    • offene Dateien

  • is analog zu Hardware's Prozesser-Kontext

• Vorteil Prozesse:

  • Daten und Anwendungen voneinander geschützt

    • durch Hardware unterstützt

    • Exception, wenn Prozess außerhalb seines Bereichs zugreifen will

  • z.B. in Apache Webserver verwendet

• Threads je Prozess

  • eigener Code, unabhängig voneinander

• kein Aufwand für concurrency transparency

  • nur minimum an CPU informationen

• thread context

  • meist nur Prozess-Kontext

  • und wenige Infos für Thread-Management

• Anwendungsprogrammierer müssen Daten schützen

• also:

  • Prozessor-Kontext in Thread-Kontext und Thread-Kontext in Prozess-Kontext

• Folge:

  • keine schlechtere Performanz als Single-Thread

  • mehr Aufwand für Entwicklung, um Anwendungen zu trennen

    • bekannt schwierig zu implementieren

• ein Programm kann mehrere Aufgaben gleichzeitig erledigen

  • Bsp. Excel-Spreadsheet (ändern, updaten, speichern)

• transparente Prallelität möglich

  • jeder Thread eigene CPU

  • oder alle auf einer

• Interprocess communication (IPC)

  • fuer große Anwendungen, die Sammlung kooperierender Programme sind

Implementierungen in Paketen

• mit Funktionen für

  • Erstellen/ Zerstören Threads

  • Operationen auf Synchronisationsvariablen

3 Arten

1. Implementierung ausschließlich in User Space

   Vorteile:

   • billig Threads zu erstellen und zu zertören

   • Wechsel vom Thread-Kontext dauert nur wenige Instruktionen

   Nachteile:

   • many-to-one threading model

     • .= viele Threads einer einzelnen Entität zuschreiben

   • blockierender Systemaufruf blockiert gesamten Prozess, zu dem Thread gehört

     • also alle anderen Threads auch angehalten

2. Kernel kennt Threads und verwaltet sie

   Vorteile:

   • one-to-one threading model

     • .= jeder Thread ist schedulable entity

     • blockiert nicht mehr andere Threads

   • einfacher

   Nachteile:

   • jede Thread-Operation muss durch Kernel ausgeführt werden - verlangt also Systemaufruf

   • Thread-Kontext wechseln wird teuer

     • so teuer wie Prozess-Wechsel

     • Kosten aber mehr durch Caches - also wird eher dieses Modell angeboten

3. hybride Form: leichtgewichtige Prozesse (lightweight processes, LWP)

• many-to-many threading model

• Threads im User Space Implementiert, LWP im Kernel Space

  Vorteile:

  • billig Threads zu erstellen, zerstören und synchronisieren

    • braucht den Kernel nicht

  • mit genug LWP blockiert ein blockierender Systemaufruf nicht den gesamten Prozess

  • Anwendung braucht nichts über LWP wissen

  • gut für Multiprozessing auf unterschiedlichen CPU

    • kann versteckt werden

  Nachteil:

  • erstellen und zerstören von LWP nötig

    • auch teuer, aber selten

• Kommunikationslatenz transparent machen:

  • Kommunikation initiieren und gleich was anderes machen

  • Bsp. multithreaded Browser stellt Daten dar, wie sie reinkommen (und wartet nicht auf alle)

    • sobald Haupt-HTML geholt wurde, können andere Dinge gemacht werden

    • Browser sieht nur Verzögerungen bei Bildern

    • außerdem: mehrere Verbindungen gleichzeitig offen

      • fuer die gleiche Seite

      • um Daten parallel zu holen

      • auf Serverseite auf verschiedene Anbieter der gleichen Seite

• code für jeden Thread ist einfach und gleich

multithreaded servers

• hauptsächlicher Ort, um Mutltithreading einzusetzen

• vereinfacht Server Code erheblich

  • z.B. für File-Server:

• einfacher Server zu entwickeln, die hohe Performanz durch Parallelität erreichen

• multithread

  • ein Dispatcher Thread verteilt Arbeit auf Worker-Threads

  • die machen ihre Arbeit und werden ggf. blockiert - währen alle anderen weiterarbeiten

• single-thread-Prozess (sequentiell)

  • nur ein Prozess, der alles nacheinander abarbeitet

  • keine Parallelität -> langsamer

  • einfacher Code

• gegenüber einem asynchronen Prozess: "finite state - machine"

  • d.h. Prozess wird nie blockiert und behandelt Anfragen asynchron

    • erhält Anfrage, gibt sie weiter

    • bekommt Antwort, gibt sie weiter

  • keine Blockierungen, außer wenn nichts zu tun ist

  • hohe Performanz durch Parallelität aber schwerer zu Programmieren

also:

• Multithread = Parallelität und Blockierungen

  • Blockierungen vereinfachen Programmierung

    • sehen aus wie Prozeduraufrufe

  • Parallelität erhöht Performanz

• Multi-Prozess wäre auch möglich

  • dann wieder bessere Trennung

  • aber schlechter, wenn Prozesse viel Kommunizieren müssen wegen Overhead

• alternativer Ansatz:

  • client machine hat für jeden remote service einen einzelnen Gegenspieler

    • bsp. Calender auf Smartphone, der sich mit geteiltem Kalender synchronisiert

    • Anwendungsebenen-Protokoll macht die Synchronisation

• anwendungsneutrale Lösung

• client machine ist nur Terminal und braucht nichts lokal speichern

  • alles auf Server verarbeitet und gespeichert

• vereinfachen System-Management

• Bsp. X windows system

Ansammlung von Rechnern in einem Netzwerk, auf denen ein oder mehr Server laufen

Schichten:

1. Front end: ein oder mehrere logical switches verteilen die Aufgaben

2. Back end: Anwendungen die Anfragen bearbeiten

3. Verteilte Daten auf die Anwendungen zugreifen (manchmal nicht verwendt und nur 2 Schichten)

1. Daemon sagt Port für Service

2. Superserver gibt Anfrage weiter

• stateless

  • speichert keine Info über Zustand von Client

    • braucht es nicht, macht es schon

  • kann Zustand ändern, ohne Client zu informieren

  • z.B. Webserver

• soft state

  • art von stateless

  • Server hat für kurze Zeit Zustand für Client

  • z.B. Server, der Client über Updates informiert

• stateful

  • behält Informationen über Client

    • Info muss explizit gelöscht werden

  • z.B. für lokale Kopie einer Datei

    • braucht dann Tabelle mit (client, file) entries

  • bessere Performanz als stateless bei bestimmten Aufgaben

  • Unterschied

    • (temporary) session state

    • permanent state

• bietet selbst keinen bestimmten Service

• Objekte auf dem Server bieten Services

  • die können aufgerufen werden

  • Services leicht veränderbar durch Hinzufügen von Objekten

  • transient object

    • existieren max. so lang wie Server (oder kürzer)

    • z.B. Taschenrechner

  • servant

    • Code-Teil der ein Objekt implementiert

1. NAT = Network-Address Translation

   • Switch bleibt in der Mitte zwischen Client und Server

   • überschreibt Quell- und Ziel-Adressen, wenn er TCP-Segmente weiterreicht

2. transport-layer switch - TCP Handoff

   • Switch auf der Transportschicht

   • TCP-Handoff

   • einfachste Verteilung: Round-Robin

     
     

1. content-aware request distribution

   • auf Anwendungsschicht

   • Switch schau auf Payload = inhaltsbewusste Anforderungsverteilung

   • z.B. ein Server ist für bestimmte Dokumente bei HTTP-Anfragen zuständig

   • ermöglicht besseres Caching und dedicated Server

= Anzahl Maschinen, die durch ein Netzwerk verbunden sind

• jede Maschine hat einen oder mehrere Server

Arten:

1. Local-area Cluster

2. Wide-area Cluster

• hohe Bandbreite

• geringe Latenz

Aufbau 3 Schichten:

1. (logischer) Switch zum Routen von Client-Anfragen

   • entweder geben sie Anfragen nur weiter

   • oder senden selbst die Antworten zurück

   • auch "front end"

2. Server für Anwendungs-Verarbeitung

3. Server für Daten-Verarbeitung

2 Schichten sind auch möglich:

• jede Maschine hat eigenen Speicher

• gehören einer Organisation

• Server/ - Cluster sind übers Internet verstreut

• um nicht mit verschiedenen Organisationen arbeiten zu müssen, vewendet man einen Cloud provider

  • e.g. Amazon, Google

  • die haben verschiedene Data Center weltweit

• redirection policy

  • um Server in der Nähe des Client zu finden

  • Möglichkeit: dispatcher ist Domain Name Server (DNS)

    • nicht gut, wenn anderer lokaler DNS als Proxy funktioniert und der gar nicht so lokal zum Client ist

    • oder dispatcher könnte anderen DNS mit Client verwechseln

• mobility support for IP version 6

• bei distributed server, wenn die Server billige Maschinen sind

  • sollen transparent als eine reliable Maschine erscheinen

• gibt verteilten Server stabile Adresse

  • Server Cluster hat einzige Kontaktadresse

    • verschiedene Server können sich dort beim home agent hinterlegen

• mobiler Knoten

  • hat Heim-Netzwerk mit home address (HoA)

    • Adresse ist stabil

    • hat speziellen Router: home agent

      • der kümmert sich um Verkehr, wenn Mobile Node weg ist

  • ist Knoten unterwegs

    • verbindet sich zu fremden Netzwerk

    • bekommt temporäre care-of-address (CoA)

      • wo Knoten erreicht werden kann

    • Home agent bekommt die Adresse und leitet Anfragen weiter

• home agent und access point wären Bottleneck

  • Lösung: route optimization

    • home agent speichert care address

    • Verkehr geht gleich dahin

    • Clients speichern andere C-Adress, denken aber immer noch mit Server auf home adress zu kommunizieren

1. Instruction set architecture (ISA)

• zwischen hard- und software

• Menge von Maschinen-Instruktionen

• 2 Untermengen:

  • a) priviligierte Instruktionen

    • nur OS darf sie ausführen

  • b) generelle Instruktionen

    • jedes Programm darf sie ausführen

1. System calls

• durch OS angeboten

• oft durch API verborgen

1. Application programming interface (API)

• library calls

a) process virtual machine

• nur für einen Prozess

• runtime system das abstrakte Instruktionen für Ausführung von Anwendungen anbietet

• Bsp. Java VM und Windows auf Unix

  
  

b) native virtual monitor

• system als Schicht über Hardware

• bietet gleiche Instruktionen wie Hardware

• simultan für verschiedene Anwendungen

• verschiedene Gast-OS können auf gleicher Maschine laufen

  
  

c) hosted virtual machine

• läuft über vertrauterm host OS

• virtual machine monitor kann Angebote von host OS nutzen (braucht spezielle Privilegien)

• Cloud Computing

3 Arten von Services

1. IaaS (Infrastructure as a Service)

• Basis-Infrastruktur

• hier VMs

1. Platform-as-a-Service (PaaS)

• Systemebenen-Services

1. SaaS (Software as a Service)

• Anwendungen

• Client schickt Anfrage an Web-Switch

• Switch gibt Anfrage weiter an Ziel-Server

• Ziel-Server antwortet Client direkt, gibt aber IP-Adressse des Switches als Sender an

  -> Handoff ist transparent für Client

• Client sendet weitere Kommunikation an Switch, der es an Server weitergibt

• für Wide-area Cluster

• Server nah am Clienten

• einfach zu implementieren

• transparent für Clienten

  • DNS kann verschiedene Adressen für denselben Host zurückgeben

• Client-Seite braucht keine ortsbewusste Software