MiniSkript Verteilte Systeme

Transkript

1 MiniSkript Verteilte Systeme - 1 -

2 Programmaufbau: a) monolithisch (Aus einem Stück) b) modular (aus Teilen bestehend) b1) Unterprogramme b2) Eigenständige Programme b2i) auf 1 Maschine b2ii) im Netzwerk Verteilte Systeme: Sammlung eigenständiger, miteinander kommunizierender Programme Funktionale Verteilung, Verteilung der Funktionalität Ein verteiltes System ist eine Sammlung autonomer (Nebenläufig), kooperierender (Kommunizierender) Verarbeitungseinheiten (Prozessoren, Prozesse / Threads, Anwendungen) Transparenz: Aussage in welchen Ausmaß ein System als Einheit erscheint. FTP: nicht transparent NFS: transparent Gegenstander der Verteilung Daten Leistung Funktionen... Vor- und Nachteile einer Verteilung Ressourcen nutzen Strukturierung Sicherung Sicherheit... Kommunikation: gemeinsamer Speicher oder Nachrichtenübertragungssystem o send (Empfänger, Nachricht) o receive (Sender, Puffer) Kommunikationsmodelle: Client (nimmt Dienst in Anspruch) / Server (bietet Dienst an) [asymetrisch] Peer - to - Peer [symmetrisch, weil beide gleichberechtigt] Arten von Clients: thick Client : Enthält Teile der Anwendungslogik lokal thin Client : Großteil der Arbeit auf Seiten des Servers - 2 -

3 n-tier-architektur Ebene / Schicht 3 - Tier Schicht: Client (Browser) <-> Webserver <-> Datenbankserver Middleware: Client <-> CORBA <-> Server Die Common Object Request Broker Architecture kurz CORBA ist eine objektorientierte Middleware, die plattformübergreifende Protokolle und Dienste definiert und von der Object Management Group (OMG) entwickelt wird. CORBA ermöglicht das Erstellen verteilter Anwendungen in heterogenen Umgebungen Schnittstellen = Compiler Pragmas (Handlung, Beziehung) 1) Prozesse: a) Multiprogramming: Mehrere Programme im Hauptspeicher, zwischen Programmen kann hin und her geschaltet werden. Programm arbeitet bis es fertig ist, oder ein IO Zugriff notwendig wird. Grund hierfür ist, dass ein IO Zugriff 1000 mal langsamer als eine Rechnung ist. b) Time Sharing Zeitscheibe, Zähler der heruntergezählt wird. bei a und b wird nicht das Programm unterbrochen sondern die Abarbeitung des Programms. Synonym für Prozess: Task: Ausführung eines Programms Ein Programm ist etwas statisches, ein Prozess ist etwas dynamisches, hat eine Lebensdauer c) a) und b) zusammen wird als Multitasking bezeichnet 1.1) Adressraum eines Prozesses: (Programme haben keinen Adressraum, nur Prozesse) Befehle des Programms wird in den Hauptspeicher geladen (Text Region oder Code Region). Data Region für globale Variablen Stack Region (Rücksprungadressen, lokale Variablen Alle Regions befinden sich im Hauptspeicher. 1.2) Umgebung eines Prozesses: Sammlung von Variablen die zu dem Prozess gehören. Die Shell ist ein Prozess, Variablen der Shell: PATH, HOME, USER In System.Properties kann in Java die Umgebung abgefragt werden. system.getproperties(); => Sammlung von Paaren der Form (key, p.getproperty(key)) p.getproperty(key) <=> Variable, Wert - 3 -

4 1.3) Prozesszustände: Ein Prozess ist immer in genau einem der folgenden Zustände new ready running blocked dead wenn ein Prozess erzeugt wird ist er new, er wurde erzeugt aber noch nicht gestartet wartet auf den Prozessor wenn er die CPU bekommt, ist er running. Er hat den Prozessor letzter Befehl abgearbeitet, wenn nicht abgearbeitet aber Zeitscheibe zu Ende, wird Prozess von Running auf Ready gestellt wenn z.b. IO-Vorgang wird Prozess auf blocked gestellt bis IO Vorgang beendet. Wenn IO beendet, wird Prozess wieder Ready wenn Prozess dead ist wird er vom Garbage Controler aus dem Speicher entfernt. Es gibt kein weg zurück wenn er Dead ist, allerdings sind seine Variablen noch abfragbar solange er noch im Hauptspeicher liegt - 4 -

5 1.4) Scheduling Zuteilungsstrategie um Prozesse den Prozessor zur Verfügung zu stellen. Kriterien: o fair o effizient => Prioritätssteuerung (echtzeitfähig) => Prozesse können verhungern o dialogunterstützend o... Beispiel für faires Scheduling: Round Robin: Alle Prozesse liegen kreisförmig um den Prozessor, Kreis hat eine Orientierung, immer der vorderste hat den Prozessor. Faires Scheduling ist gerade in Real Time Systemen unerwünscht => Prioritätssteuerung 1.5) Prozessverwaltung: Zustand (in welchen Zustand ist der Prozess) PID (laufende Nummer) User-ID TTY (Terminal) Zeit(en) Cmd (das zu dem Prozess geführt hat) ) Prozesse starten Bsp: # cat a.txt Das Programm cat startet einen Prozess. Prozesse teilen sich in Threads auf 2) Threads - Verfeinerung des Prozessmodells - Kritik am Prozessmodell: Prozesskommunikation: Prozesse tauschen Daten über das Betriebssystem aus, sehr aufwendiges Verfahren Prozesswechsel T1 D1 S1 T2 D2 S2 wenn ich von T1 nach T2 will kann ich nicht einfach den Programmcounter (PC) umsetzten. Prozesswechsel ist eine sehr aufwendige Aktion, da man sich sehr viel merken muss

6 Bsp: # a.p print "Ich bin der Vater\n"; $pid = fork; if($pid == 0) { print "Ich bin der Sohn\n"; exit; } print "Ende\n" Reihenfolge der Ausgabe nicht verhersagbar!! Alles wird ausgegeben, aber Ende kann vor oder nach Sohn kommen. Ein Thread ist die Erzeugung eines zweiten (virtuellen) Programmcounters (Programmzählers) auf der gleichen Text Region Beide Programmcounter benutzen die gleiche Data Region aber unterschiedliche Stacks Befehlszähler = Programcounter Zeigt immer auf den nächsten auszuführenden Befehl (gibt es immer nur einmal!) Counter im Betriebssystem = > Befehl cat wird ausgesetz Betriebssystem richtet Regions im Hauptspeicher ein, Counter zeigt auf Beginn von Stelle a am Anfang von T1, dann folgt D1 und S1, soll später ein 2. Befehl abgearbeitet werden, legt ein 2. Prozess an der Stelle b) am Beginn von T2 an, sowie D2, S2. Scheduler entscheidet wer den Prozessor bekommt, schaut an Stelle a) nach wer den Programcounter bekommt. => Prozess 1 arbeite, Zeitscheibe läuft, Programcounter kommt im Code voran - 6 -

7 Zeitscheibe abgelaufen, Betriebssystem merkt sich Abbruchstelle => wenn Prozess 2 Programmcounter bekommt startet Prozess 2 => Zeitscheibe abgelaufen => Programcounter beim Betriebssystem Programcounter wird vom Betriebssystem wieder auf a(2) gesetzt => Hat nichts mit Threads zu tun!! Wenn wir Programcounter bekommen können wir entscheiden in auf a, b oder c zu setzen => Wir bekommen Zeitscheibe, Möglichkeit 1) Wir teilen Zeitscheibe "gerecht" durch 3, und teilen Zeitscheibe auf 3 Threads (a,b,c) auf. Prozess teil sich auf Threads auf. Ein Prozess enthält Threads bisher: Innerhalb eines Prozesses hatten wir nur einen Thread (MainThread (gibt es immer!)) Vorstellbar: Prozesshülle, darin laufen unabhängige Threads, aber so ist es nicht, weder in Java noch in Posix: Programm beginnt immer mit Main-Thread Schon nach dem 1. Befehl kann Main-Thread sich teilen, so entsteht immer ein Baum, Threads können sich in andere Threads teilen Unterschied: Verwalte ich pro Prozess nur einen Thread oder mehrere? Frage: Was sieht das Betriebssystem von dem ganzen? Antwort nicht pauschal, es gibt Systeme die sehen Threads (Multithreading) oder welche die sehen keine (SingleThread). Java zeigt sich immer als 1 Thread und macht den Rest selbst => BS sieht nur virtuelle Javamaschine, Aufteilung in Threads erfolgt von Java selbst - 7 -

8 Java: Threads erzeugen class mythread{ public static void main(...) { System.out.println("Ich bin " + Thread.currentThread().getName()); } } $: Ich bin main Threads zur Erzeugung von Threads 2 Möglichkeiten: 1. Thread ableiten von Klasse Thread 2. Implementieren der Schnittstelle runnable in Wirklichkeit nur ein Verfahren, da Thread Runnable implementiert und in 2. vererbt. In beiden Fällen muss eine run() - Methode ausprogrammiert werden. Die Aktionen von run() sind der (zusätzliche) Thread (main Thread existiert ja sowieso) 1) Thread ableiten [Code Sample. 1] => keine Vorhersagbarkeit möglich welcher der Threads (main, mythread) zuerst aufgerufen wird. Namen von Threads: Vorgaben: main Thread-0 Thread Eigene Namen: a) setname("...") b) Konstruktor: Thread("...") 2) Threads durch Runnable implementieren: [Code Sample 2] Prozessende: Ende Prozess => Ende aller seiner Threads System.exit(n); // n = int Wert Thread-Ende: Es gibt kein Thread - Exit! Um Thread zu beenden muss run() beendet werden => folg. Konstruktion: run() { while(!fertig) {...} } // Steuerung über boolsche Variable - 8 -

9 Garbage Collector in Java entfernt Threads nur wenn keine Referenz mehr auf ihn verweist. Bsp. mt = null oder t=null; Timeouts setzen: public static void sleep(ms); Thread.sleep(300); Schläfer aufwecken: public void interrupt() Synchronisation mit dem Threadende: Ein Vater wartet auf das Ende eines Sohnes: public final void join() throws InterruptedException Code Sample 3: Berechnung von (a1 + a2) * (a3 + a4) public final boolean isalive() - schon Ready?? Java - Scheduling: Prioritätssteuerung ( 0 min, 10 max) höchste Zahl bekommt Proz, bei gleicher höchster Zahl => RoundRobin Standardpriorität = 5 Prioritäten können nur innerhalb des Prozesses umgesetzt werden. public final void setpriorrity(int prio) Thread kann Prozessor abgeben, verzichten public static void yield(); - 9 -

10 Kommunikation zwischen Prozessen und zwischen Threads: Lokale Verfahren -> nicht rechnerübergreifend Shared Memory: Gemeinsamer Hauptspeicherbereich Bei Prozessen: Getrennte Adressräume => Das BS muss vermitteln Unix: Adressraum (Text, Data, Stack) wird erweitert um eine Shared Memory Region Es gibt nur eine Shared Memory Region die vom BS verwaltet wird. P1 und P2 haben je 4 Regions, allerdings ist die jeweilige Shared Memory Region die SharedMemoryRegion des BS, von der die Prozesse nur "denken" es sei die ihre. Achtung beim schreibenden Zugriff Jede Manipulation des SharedMemoryRegion bedarf einer Reihe von Systemaufrufen (System Calls) SharedMemoryRegion "überlebt" seine Prozesse Threads haben eine gemeinsame Data Regio => Kann sie als Shm benutzen Achtung: Hier "überlebt" das Shm nicht. Code Sample 4: Java Bsp: Pipes: "anschaulich": Röhre zwischen 2 Prozessen (gerichtet) byteorientiert => INT als 2 bzw. 4 Bytes Realisierung als temporäre Hauptspeicherdatei (ohne Plattenplatz) Pipe überlebt ihren Prozess nicht Die Datei ist FIFO organisiert Pipes sind Prozesskommunikations - Mittel

11 Verallgemeinerung bei Unix und Win (ab NT) Named Pipes: Wie eine Pipe, aber "richtige" Datei. Sie überlebt ihre Prozesse Zugriff auf Pipes: Nur mit System Calls Erzeugen Schreiben Lesen Wie kommt ein Prozess an die Pipe? Nur durch Vererbung Der fork()-aufruf verdoppelt einen Prozess => er vererbt seine Deskriptoren Auf Shell Ebene: -> $ who wc -l Code Sample 5 Pipes (Perl Bsp) Pipes sind weit verbreitet, einfach und mächtig. Jedoch: P1 will "a" an P5 schicken. Funktioniert mit Pipes nicht, da "a" einfach in die Pipe geschmissen wird und keinerlei Kontrolle hat ob P4 oder P5 es weiterverarbeitet. Deshalb wurde eine weitere Methode entwickelt => Message Passing! Shared Memory (synchron) Pipes (synchron) Message Passing (assynchron) alle lokal

12 Message Passing: Das BS verwaltet ein Array von Zeigern i anfangs leer. Eine Menge ist anschaulich Kennzahl Text Besitzverhältnisse wie bei einer Datei Lebensdauer wie bei einer Datei Die Kennzahl heißt oft "Typ" der Nachricht Der Sinn: Der Leser kann damit eingeschränkt selektieren Bsp: - Ein Leser könnte sagen: Gib mir aus der Queue 0 die älteste Nachricht - Ein Leser könnte sagen: Gib mir die älteste Nachricht vom Typ 5 Rechnerübergreifende Verfahren - Sockets - Sockets (Sockel): Endpunkt von Kommunikationseinrichtungen, Sockets sind bidirecktionale Pipes! 1) Alle Internet Dienste benutzen Sockets Host1: Prozesse: FTP-Client (ip) <-> Internet (Adressen) <-> Host2: Prozesse FTP-Server(ip)

13 ARP (Adress Resolution Protocol) IP-Adresse -> HW-Adresse Um Daten auszutauschen müssen auf beiden Seien beide Sockets voll spezifiziert sein Ein Socket ist die Programmierschnittstelle zu den Transportprotokollen TCP und UDP. [Für privilegierte Prozesse: RAW-Sockets: Zugriff auf IP] TCP Socket auf der einen kann niemals mit UDP Socket auf der anderen Seite verbunden werden. Bsp: Socket = (TCP/ UDP, local Host, local Port, remote Host, remote Port) H1: (TCP, , 2012, , 21) <-> Internet <-> (TCP, , 21, , 2012) : H2 Anschaulich entsteht eine bidirektionale Pipe Ein Port ist ein Synonym für die Prozess-ID! Er identifiziert einen Prozess auf einem Haus. Portlist: /etc/services Regelung: Ports von sind priviligiert (Well Known Ports) Ports von von TCP/IP vergeben und überwacht Port über 5000 frei verfügbar 16 Bit Zahlen < Möglichkeiten UDP: leichtes, schnelle Protokoll. Erweitert IP um die beiden Ports. Keine Kontrollen, kein Acknowledge, symmetrisches Protokoll (bei Empfänger und Sender laufen die gleichen Abläufe ab, Symmetrie zwischen Sender und Empfänger) TCP: Handshake zur Eröffnung der Kommunikation Flusskontrolle (zählt gesendete Bytes) Sliding Window (gegen Pufferüberlauf beim Empfänger), kein Pufferüberlauf möglich => Sichere Verbindung mit Streams TCP - Server - Socket muss als erster Starten TCP * * Socket muss, kann nur warten Wenn ein Client "anklopft", kann der Server die Clientinformation auslesen: Client, , Port 1088 klopft an Server verdoppelt seinen Socket TCP Kommunikation kann laufen

14 Anwendung im Internet: Web: Server an Port 80 TELNET: Terminal an einem fremden Rechner Client: Nimmt Benutzereingaben und gibt sie ungefiltert an den Server => Muss dazu einen Socket einrichten ->$ telnet [Servername] 80 => Socket: [ TCP [Servername] 80 ] -> Trying Connected to www Escape Character ist '^J' -> GET / HTTP/1.0 } HTTP -> Leitseite der TFH (HTML) Namensauflösung: Alle Dienste arbeiten auf IP-Adressen Weitere Dienste: www => Client Server Modell Serverseitige Programme (CGI, Servlets) Clientseitige Programme (Applets, Javascript) Java Sockets: 2 Ebenen: hoch: URLs tief: Sockets

15 Klasse URL try { URL url = new URL(" } catch (Exception e ) {} [Code Sample 19] Socket Ebene: Klassen: Server: Serversocket, Socket Client: Socket TCP - Socket Socket von (TCP, Localhost, LokalPort, RemoteHost, RemotePort) beim Client: Socket cs = new Socket("HRZ", 8761); // alle 5 Infos komplett, weil die lokalen Angaben das Socket kompletieren (Transportprotokoll, Lokalhost, Lokalport) beim Server: ServerSocket ss = new ServerSocket(8761); // wartet auf Anfragen auf angegebenen Port, bei Anfrage kopiert sicher das Serversocket in ein Clientsocket und kompletiert dies mit Angaben des Clients UDP - Socket Datagramme werden gesendet und empfangen, es sind Bytearrays zusammen mit der Socketinformation. Empfänger benötigt ein genügend großes Bytearray um Informationen aufnehmen zu können. Byte[] b = new Byte[512]; DatagramPacket dp = new DatagramPacket(b,b.length()); DatagramSocket ds = new DatagramSocket(7654); ds.receive(dp); dp.getdata(); Nun möchte Sender Strring übertragen String s = "Hallo"; Byte[] b = s.getbytes(); // nun gibt es ein kleines Problem, wir brauchen IP Adresse haben aber bloß einen Hostname. InetAdress host = InetAdress.getByName(" DatagramPacket(b, b.length, host, 7654);

16 RPC (Remote Procedure Calls) und NFS (Networking File System) Abstraktion: Remote Procedure Calls (RPC) (ursprünglich von SUN: Unterstützung von NFS) RPC gehört in Ebene 5, Kommunikationssteuerung im OSI Kommunikationsmodell: main () {... y = sin(7.4);... } sin(7,4) aus Bibliothek sinx(x) { Rechenabwicklung; return (erg); } Server: sin(x) { Sende x zum Server warte auf erg; return (erg); } Zeitdiagramme: Client: Server: start > Bearbeitung < Rückgabe Der RPC ist fast transparent! y= sin(5,0); Bei RPC gibt es keine Calls By Reference, klar denn die Adressräume stimmen nicht überein. Rettungsversuch: Die gesammte Data Region übertragen und Adressraum relativ angeben. (Java Lösung) RPC ist ein Protokoll auf OSI / ISO Schicht 5, es setzt auf UDP auf. JavaSysteme setzten auf RPC auf

17 Anwendung: NFS alternativ dazu DFS (Distributed File System) Grundlagen Mounting: Dateisysteme zum einen Logisch: o physisches Dateisystem wird zu logischen Dateisystem erklärt o in ein leeres Verzeichnis wird Dateisystem eines entfernten Systems per NFS gemountet. Physisch: o Festplatte, organisert in Sektoren und Zylinder Sonderformen: Realisierung von NFS über ein sog. virtuelles Dateisystem, wie logisches DS, nur mit dem Unterschied dass das zu mountende DS sich auf einem entfernten Rechner befindet. XDR: External Data Representation Darstellung der Zahlen und Zeichen verpflichtet den Sender zur Einhaltung einer Norm für Zahlen und Zeichen Globale Benutzerverwaltung für NFS notwendig => Yellow Pages/ Network Information System (NIS) Prozeduraufrufe: Parameter -> Parameterübergabe NFS: Mounting VSF: Virtuelles Filesystem XDR, RPC (nicht objektorientiert), UDP, IP o Java: RMI (Remote Method Invocation) = Java Implementierung der RPC (benutzt TCP)

18 Prozessmodell: Serverseitig: Serverhost -> RegistryProzess (Server meldet sich beim RegistryProzess an) Clientseitig Clients wenden sich nicht an Server, sondern an Registry Prozess) => Kommunikation zwischen Client und Server Abstrahierung von den Sockets: Stab (Stummel) und Skeleton (Sklett) Vorgehensweise (grob): Die Methoden, die der Server anbieten soll, werden in einem Interface deklariert Serverseitig werden Stub und Skeleton erzeugt. Tool verhanden. Ab Java 1.2 entsteht keine Skeletonklasse mehr. Die Stub Klasse wird zum Clienten kopiert Serverseitig wird der Registry Prozess gestartet. Dann startet der Server. Er meldet sich beim Registry Prozess an. Client wendet sich an den Registry Prozess Feinrealisierung am Bsp. eines Zeitservers: Aufgabe: Server gibt Uhrzeit zurück. Client läßt sich 2 * die Zeit geben. Bildet Differenz: Ist grobes Maß für die Dauer einer RMI

19 RMI (Remote Method Invocation) A: Serverseitig Arbeiten A1: Interface schreiben [Code Sample 6] A.2: Server schreiben: [Code Sample 7] - Achtung: Ist ein Mehrfachserver. Wird übersetzt mit einer Endlosschleife nach dem letzten Befehl. A3: Server übersetzen: -> javac ZeitServer.java => ZeitServer.class; ZeitInterface.class A4: Stub & Skeleton erzeugen: -> $ rmic ZeitServer => ZeitServer_Stub.class; [ZeitServer_Skel.class] 1.2 A5: Registry starten: -> $ rmiregistry 1099 & A6: Server starten: -> $ java ZeitServer [&] -> $ ps => sh, ps, jre (Registry), java B) Client Arbeiten: B1: Client schreiben [Code Sample 8] B2) Interface zum Client holen (FTP), Orginal bleibt beim Server B3) Stub Klassse zum Client holen FTP, Orginal bleibt beim Server B4) Client übersetzen: javac ZeitClient.java B5) Client starten: java ZeitClient CORBA (Common Object Request Broker Architecture) [ab 1989] sprachunabhängig betriebssystemunabhängig architekturunabhängig Idee: Anwendungen I Netz <--> ORB <--> Netz Zahl der Implementierungen ist klein geblieben. Grund: Zu allgemein angelegt Folge: Konkurenzprodukute -> COM : Microsoft (Common Object Model) =>.NET DCE : Distributed Common Enviroment von der OSF (Open Software Foundation / Unix) IDL: (Interface Definition Language) zur Beschreibung der Objekte Anwendungsgebiete (Empfehlung): zeitkritische Anwendungen: Sockets heterogene Umgebung : CORBA, DCE Microsoft Umgebung : COM ->.NET Java Umgebung: RMI

20 Weitere Entwicklung: Anbieter --> Dienstangebot => Beschreibung des Dienstes (lesbar HTML, f. Menschen) Prob.: Niemand weißt von meinem Dienstangebot => Beschreibung,Werbung notwendig, wie wird der Dienst benutzt, wie in Anspruch genommen Was wenn der entfernte Benutzer kein Mensch ist, wenn Programme die Kommunikationspartner sind. Es geht um das Verstehen der Beschreibung! Lösung: Man benutzt eine formale Beschreibung. Dokumente bestehen aus: Struktur Layout XML ist geeignet zur formalen Beschreibung von Dokumenten! Bekannte Sprachen in diesem Zusammenhang: Struktur Layout SGML DSSSL HTML /CSS XML XSL / CSS Idee der Webservices: - für den Transport der Daten: HTTP - Beschreibung der Daten: XML Bekanntmachung < Dienst > Beschreibung z.b. TCP / IP Beschreibung mit XML: WSDL (mit XML definiert worden, Web Service Description Language) Bekanntmachung: Globaler Verzeichnisdienst (im Sinne gelber Seiten) UDDI Universal Description, Discovery and Integration in XML

21 Zugriff auf TCP/IP: SOAP (Simple Objects Access Protocol --> HTTP TCP IP Aufgaben von SOAP: Formulierung eines RPC als XML - Ausdruck! Bsp: Abfragen eines Aktienkurses mit SOUP--> getquote("ibm") == RPC [Code Sample 9] Kommunikationsmodell: Anbieter ---- implementiert Dienst -- > SOAP Service -> WSDL - Beschreibung -- anmelden --> UDDI - Client sucht bei UDDI und findet die WSDL - Beschreibung. - Client erstellt SOAP Client und parametrisiert ihn mit WSDL - Beschreibung - SOAP Client und SOAP Service arbeiten über HTTP miteinander Nebenläufigkeit: - Zeitliche Abläufe - Vorher - Nachher Zeit im Computer: Taktgeber (diskrete Zeit?) Ein Zeitgeber t1 liegt vor einem Zeitpunkt t2, wenn t1 < t2 "<" heißt Vorher Nachher Relation Sie ist transitiv: a< b && b < c => a < c (Relation in N x N) Sequentiell: 2 Zeitpunkte t1 und t2 sind in Sequenz, wenn t1 < t2 oder t2 < t1 liegt. Gibt es auf einem Rechner nur einen (einzigen) Taktgeber, dann sind alle Zeitpunkte in Sequenz. Es gibt nur 1 Zeitsignal 2 Zeitpunkte t1 und t2 sind nebenläufig, wenn sie nicht in Sequenz sind. Bei nur einem Taktgeber ist Nebenläufigkeit nur dann möglich, wenn die beiden Zeitpunkte identisch sind: t1 = t2 Ereignisse Haben eine Dauer Bestehen aus 2 Zeitpunkten t1 < t2 Die Begriffe "sequentiell" und "nebenläufig" werden auf Ereignisse übertragen. Sequentialität und Nebenläufigkeit - Def. über Zeitpunkt - Übertragung auf Ereignisse

22 Regeln von Bernstein: Moderne Rechner arbeiten nebenläufig durch eine renundante Hardware und / oder das Time Sharing - Produzenten - Konsumenten Problem: Produzent: Produzent füllt Lager Lager: Lager mit 0 - n-1 Lagerplätzen Konsument: Konsument nimmt aus dem Lager Probleme: Konsument leert Lager bevor Produzent es wieder auffüllt Lager ist voll, Produzent will nachfüllen.. [Code Sample 10] Jedes der beiden Progs ist für sich korrekt! Gemeinsam sind sie falsch!! Anschaulich: Sei z = 3 Produzent ist am Zug: z = z +1 (4) TimeSharing unterbricht Konsument kommt zum Zug; Zugriff auf z = 4 => Fehler, da z = 4 leer ist Die nebenläufige Abarbeitung von z = z +1 und z = z -1 heißt kritische Situation Allgemeiner: Ein kritischer Abschnitt ist ein Bereich eines Programmes, in dem dieses Programm verhindern muss, dass andere Programme die gleichen Betriebsmittel verwenden! Im Beispiel: kr.a. im Produzenten im Konsumenten while (z == n-1); while (z == -1); z = z +1; y = Lager[z]; Lager[z] = x; z = z - 1; Anschaulich: Ein Prozess betritt den kritischen Abschnitt Prozesse müssen in der Lage sein Sperren zu setzten. Das können sein: Eigenschaften des Prozessors Eigenschaften des Betriebsystems Eigenschaften der Sprache Kleines Problem: Angenommen wir könnten bereits korreckt sperren. Situation: Prozess A hat den Drucker gesperrt und druckt

23 Prozess B hat den Plotter gesperrt und plottet Prozess A braucht kurz den Plotter Prozess B braucht kurz den Drucker Es liegt ein Deadlock (Verklemmung) vor; Jedes BS und jedes DBS muss Deadlocks behandeln. Graphisches Hilfsmittel: Anforderungsgraphen: Prozesse: o Betriebsmittel: [] o --> [] hat geperrt o <-- [] Prozess benötigt Betriebsmittel Siehe: VS2, , Bild 1 Ist im Anforderungsgraphen ein Zykel, liegt ein Deadlock vor. Was tun? a) Vermeidung b) Auflösung (Rollback) Beide sehr aufwendig!! Mittel zum Setzen von Sperren (bei genau einem Prozessor) - Methode 1: Überlegung: Ein Prozess verbietet vor dem kr. Abschnitt alle Interrupts Er kann nicht abgebrochen werden Er schließt alle anderen Prozesse korrekt aus, er sperrt korrekt Ist das praktikabel? Auf jedem Prozessor gibt es 2 Befehle: interrupt_enable; interrupt_diable; Kein Mittel für den Anwendungsprogrammierer Wird in Systemprogrammen verwendet! - Methode 2: Auf vielen Prozessoren gibt es einen Befehl (ein Makro) namens tsl() (test and set lock)

24 Implementierung: tsl(z) { interrupt_diable; merke = z; if ( z == 0) z = 1; interrupt_enable; return merke; } Eine Sperre damit setzten: while (tsl(z)); kr.ab. z = 0; - Methode 3: Boolesche Sperren (FALSCH!!!!) Setze Variable: flag = 0 // Krit. Abschnitt ist frei flag = 1 // Krit. Abschnitt ist gesperrt Prozess(i) { while (TRUE) { while (flag); flag = 1; kr.operationen flag = 0; } } Falsch weil: Es gibt keine Sperrvariablen!! Gleiche Situation wie beim Produzenten/Konsumenten Prob. Übung: Beispiele für Methode 3 finden, zeigen warum das nicht geht. - Methode 4 Striktes Alternieren flag = 0 : Prozess (1) darf in den kr. Abschnitt flag = 1 : Prozess (0) darf in den kr. Abschnitt [Code Sample 11] Die Sperre ist korrekt! Flag wird nicht konkurierend gesetz. Lösung wenig praktikabel! Bsp: lange dauernder unkrit. Abschnitt in Prozess(0) und schnellem Prozess(1) Kritischer Abschnitt: Prozesse / Threads müssen ihren kritischen Abschnitt schützen (Sie müssen Sperren setzen, müssen andere Prozesse ausschließen: Mutual Exclusion)

25 Interrupts verbieten Absolut sicher, aber ungeeignet für Anwendungsprogrammierung TSL - Befehl Sicher, aber nicht jeder Prozessor hat einen solchen Befehl Boolsche Variable (Sperrvariablen) Es gibt keine Sperrvariablen Striktes Alternieren Lösung wenig praktikabel! Bsp: lange dauernder unkrit. Abschnitt in Prozess(0) und schnellem Prozess(1) Petersons Lösung (Weiterentwicklung/Verinfachung vondekker) Idee: (Bild1, ) Ang. Person(0) will in den kr. Abschnitt: 1. Läuft links zum Tisch 2. Legt roten Hut auf den Tisch 3. Liegt in der linken Schale eine Murmel, dann legt sie sie in die rechte Schale Angenommen Person (1) ist weit entfernt! Dann sieht Person(0) keinen weißen Hut. Sie geht in den kr. Abschnitt Jetzt kommt Person(1) Läuft rechts zum Tisch Legt Ihren weißen Hut auf den Tisch Legt die Murmel von Links nach Rechts Sie sieht einen roten Hut und weiß: Es ist jemand in kr. Abschnitt => sie wartet! Verläßt Person(0) den kr. Abschnitt, setzt sie ihren roten Hut wieder auf. => Person(1) geht in den kritischen Abschnitt Angenommen, beide konkurieren: 1a: Läuft links zum Tisch 1b: Läuft rechts zum Tisch 2a: Legt ihren roten Hut auf den Tisch 2b: Legt ihren weißen Hut auf den Tisch 3a: Liegt die Murmel links, wird sie von P(0) nach rechts gelegt 3b: Liegt die Murmel rechts, wird sie von P(1) nach Links gelegt. Einer der beiden wird der letzte sein, und der wartet. [Code Sample 12] Petersons Lösung ist korrekt! Aber: Verallgemeinerungen auf n Prozesse sind sehr aufwendig. Es wird nach "Besseren" Lösungen gesucht

26 Gibt es Hilfen über das Betriebssystem? Gibt es geeignete System Calls? In der Regel machen die Handbücher keine Aussage, ob ein Aufruf unterbrechbar ist. Deshalb sind spezielle Sperrbefehle, sog Semaphore, entwickelt worden. in der UNIX Welt: creat(9 ist ununterbrechbar. creat("a.txt"); => existiert a.txt und ist schreibgeschützt, dann return -1 sonst wird die Datei angelegt. while (creat("a.b") == -1); kr.abb..; unlink("a.b"); => korrekte Sperre gesetzt! => Aber: Quick & Dirty, Gefährlich wegen Prüfung der Rechte (root..) => deshalb sind die Semaphore entwickelt worden! Dijkstra (~ 1965) Griechisch: Signalanlage Strutur eines Semaphors: class Semaphor { int wert; // Semaphorwert void P() { s.u. } void V() { s.u } queue L; // Warteschlange } P => Passieren V => Verlassen [Code Sample 13] Idee: Ist s.wert negativ, gibt s.wert (Betrag von s.wert an, wieviele Prozesse in der Warteschlange sind) Bsp: 3 Prozesse, alle machen s.p() kr.a. s.v(); s.wert = 1 Prozess1 s.p() 0 kr.abschnitt Prozess2: s.p() -1 sleep Prozess3: s.p() -2 sleep Prozess1 s.v() -1 wakeup

27 Prozess2: kr.a. s.v() 0 wakeup Prozess3: kr. Ab.. s.v(); 1 Erste Anwendung: Produzent/Konsument Problem; korrekte Lsg. [Code Sample 14] Das Leser/Schreiber Problem: - Es gibt ein Datum D (Feldwert, Satz, Tabelle, DB) - Es gibt Prozesse die D verändern: Schreiben - Es gibt Prozesse die D nur lesen: Leser Das Problem: Zu jedem Zeitpunkt ist D entweder frei, oder es wird von genau einem Schreiber bearbeitet und es gibt keinen Leser oder D wird von n Lesern gelesen und es gibt keinen Schreiber. Idee: D sperren und mit R die Leser zählen. [Code Sample 15] 5 Schreiber und 5 Leser: 1. Schreiber: sperrt D schreibt 2. Schreiber schläft auf D 1. Leser: sperrt R R = 1 schläft auf D 2. Leser schläft auf R Rendevouz: 2 Prozesse / Threads o Prozess1 hat Stelle A o Prozess2 hat Stelle B Der Prozess, der als erster diese ausgezeichnete Stelle erreicht, wartet, bis der ander auch soweit ist. Dann arbeiten beide asynchron weiter. [Code Sample 16]

28 Gefahren: Angeommen man verwechselt P und V => Absolut blöde.. alles rennt in den krit. Abschnitt Folge daraus: Entwicklung eines abstrakten Serrkonzepts. Monitore werden durch Semaphore implementiert. Benutzer arbeitet nicht mehr mit P() und V(). Idee: Raum läßt immer nur einen Prozess eintreteten. Monitor: Sperrkonzept auf hoher Abstraktionsstufe Idee: Intelligenter Raum Der Monitor lässt immer nur höchstens einen Prozess eintreten Monitor bekommt ein Nebenzimmer, ein Warteraum in den alle Prozesse warten (schlafen) die schon den Monitor Raum betreten haben, diesen aber blockieren.) Java Realisierung: In Java ist jedem Element aus der Klasse Objekt ein Monitor zugeordnet Der Monitor wird aktiv mit dem Schlüsselword synchronized. Ausprägungen: (1) synchronized (object) {... } (2) synchronized (static object) {... } (3) synchronized type method (..) {...} // übliche Verwendung (4) static synchronized type method(...) {.. } Bsp. 2 Threads konkurieren um einen Zähler! [Code Sample 17] Ein Thread vesucht einen Monitor zu betreten, indem er eine synchronized Methode aufruft. (Synchronized Methoden sind Objektbezogen, es geht immer um Objekte die geschützt werden) Java: Zulässig, dass eine Methode im Monitor erneut eine synchronized Methode aufruft. Reentrant oder Wiedereintrittsfähig. Blockierung am Monitor: Ein Thread im Monitor, der nicht weiterarbeiten kann, ruft: - public final void wait() throws InterruptedException {.. } Ein Thread kann aus dem wait() nur durch einen anderen Monitor Thread befreit werden. Er bekommt dann ohne weitere Prüfung den Monitor zurück. Geweckt wird mit public final void notify() oder aber public final void notifyalll(); // notifyall weckt alle (wobei der erste gewinnt (der zuerst den Proz hat) sollte der letzte Befehl vor dem Verlassen des Monitors sein! Compiler hilft! [Code Sample 18]

29 Synchronisieren bei Multiprozessorsystemen 2 Arten: Enge Kopplung: Es gibt für alle Prozessoren eine gemeinsame Uhr (auch gemeinsamer Hauptspeicher) Lose Kopplung: Es gibt nicht viele Uhren! Das Unix make Tool: Werkzeug zur Programmentwicklung Datei namens Makefile: Ziel : Dateien Befehle Bsp: a.exe : a.b a.c tcc a.c b.c Der Witz dabei: Durch Prüfen der Zeitstempel Ziel - Dateien wird entschieden, ob die Kommandos / die Befehle durchgeführt werden. Bei einem Rechner mit einer Uhr ist make unproblematisch aber angenommen wir haben 2 Hosts und 2 Uhren: Host mit Compile: -----o-----o-----o-----o-----o-----o-----o-----o-----o-----o-----o-----o Bei 140 a.exe erzeug. Host mit Editor: o------o------o------o------o------o------o------o------o------o Bei 139 a.c Ende Editor make müsste a.exe nun erzeugen. Aber 139 < 140! => make übersetzt nicht. Fehler! In vernetzten Systemen sind alle Programme die mit Zeiten arbeiten problematisch. Lösung 1: Wir brauchen UTC: Universal Time, Coordinated wird bundesweit ausgestrahlt. Von Atomuhr erzeugt. Aufwand zu groß Lösung 2: Logische Uhren operieren auf der Vorher - Nachher Relation Rechner mit 2 Uhren -----o o > o------o > Vergleich auf dem jeweiligen Zeitstrahl ist sehr simpel möglich, erst der direkte Vergleich wird schwierig

30 Nebenläufigkeit: Zeitlicher Ablauf in einem Rechner. Quartzkristall erzeugt einen Takt. Alle Uhren (Timer) sind daraus abgebildet Anschaulich: --o----o----o----o----o----o----o-----o Diskrete Zeitpunkte Gibt es genau einen Taktgeber, dann ist von t1 und t2 immer feststallbar, ob: t1 < t2 t1> t2 t1 = t2 t1 in Sequenz mit t2, falls t1 < t2 oder t1 > t2 t1 nebenläufig zu t2, falls sie nicht in Sequenz sind Bei genau einem Taktgeber bedeutet Nebenläufig Identität (dass t1 und t2 identisch sind)! Ein Ereignis E ist ein paar von Zeitpunkten (t1 und t2) mit t1 < t2 Man schreibt E(t1,t2). Anschaulich in Zeitdiagramm E t1 t2 2. Ereignisse A(t1,t2) und B (t3, t4) sind sequentiell falls t2 < t3 oder t4 < tb A B t1 t2 t3 t4 Es gibt Ereignisfolen, die in ihrer Gesamtheit nur dann konkret sind, wenn sie sequentiell erfolge Bsp: i = 0; // Ergebnis A i = 1; // Ergebnis B Es gibt Gebiete die konstruktionsbedingt ein sequentielles Arbeiten gestatten Lochkartenleser Zeilendrucker Bandgeräte

31 2 Ereigniss A(t1, t2) und B(t3, t4) sind nebenläufig wenn sie nicht Sequentiell sind. D.h. t2 nicht vor t3 Es gibt Ereignisfolgen, die auch dann korrekt sind, wenn sie nebenläufig durchgeführt werden Bsp: i = 3 // Ereignis A i = 5 // Ereignis B Es gibt Geräte die von ihrer Konstruktion her nebenläufig arbeiten. - Rechnersystem mit 2 Druckern Parallelität und Pseudoparallelität Ist eine Hardware mehrfach vorhanden (2 Drucker, 2 Prozessoren) und wird nebenläufig betrieben, sprich man von Parallelität. Es gibt in Betriebssystemen eine weitere Möglichkeit, Nebenläufigkeit zu realisieren: - Time Scaling, Multiscaling (bei genau einem Proz) Diese Nebenläufigkeit heißt Parallelität Anwendung bei verteilten Systemen: Wir dürfen nebenläufig arbeiten, wenn die Reihenfolge der Abarbeitung keinen Einfluß auf das Gesamtergebnis hat. Alle anderen Fälle müssen sequentiell behandelt werden. Bsp: x = 0 // A x = 1 // B y = x +3 // C => Sequentialität ist zwingend, weil y keinen definierten Wert x hat. x=0 y=1 => Nebenläufigkeit ist in Ordnung z=2 Graphisches Hilfsmittel: A,B sequentielle Ereigniss: A -> B lesen als A vor B oder B nach A oft: A -> B seq. erst muss A fertig sein, dann B, Wartegraphen, auch Präzedenzgraf, Vorrangsgraph Wartediagramm: Bsp: x = 3 x = 3 y = 4 Das ist kein Flussdiagramm y = 4 y = x +y z = x + y;

32 Regeln von Bernstein: - Jeder Befehl ist mit 2 Mengen verbunden: - Die Inputmenge I(s) eines Befehls s ist die Menge aller Variablen die in die Abarbeitung des Befehls eingehen. - Die Outputmenge O(s) eines Befehls s ist die Menge aller Variablen, die durch die Abarbeitung des Befehls verändert werden. Befehl s (s) O(s) c=a-b; {a,b} {c} x = x+1 {x} {x} y = 0; {} {y} read(a) [a=read()] {} {a} System.out.println(a); {a} {} 2 Befehle s1 und s2 dürfen nebenläufig durchgeführt werden wenn alle 3 folgenden Regeln erfüllt sind: [1] I(s1) geschnitten O(s2) = {} [2] O(s1) geschnitten I(s2) = {} [3] O(s1) geschnitten O(s2) = {} Ist auch nur eine dieser Regeln verletzt, muss sequentiell gearbeitet werden. Beispiele: (1) s1: x = a+b; # Regel 1 verletzt s2: a = 7; # Muss sequenziell durchgeführt werden (2) s1: x = a+b # Regel 2 verletzt s2: y = x+1 (3) s1: x = 3; #Regel 3 verletzt s2: x = 5; (4) s1: a = x + y; #Nebenläufigkeit erlaubt, keine Regel s2: b = z +1;