CS2101 Nebenläufige und Verteilte Programme Bachelor of Science (Informatik)

Transkript

1 Prof. Dr. Th. Letschert CS2101 Nebenläufige und Verteilte Programme Bachelor of Science (Informatik) Vorlesung 7 Th Letschert FH Gießen-Friedberg

2 Ressourcen Verwaltung passive Ressourcen aktive Ressourcen aktive Verwalter 2

3 Nebenläufige und verteilte Programme Ressourcen Verwaltung passive Ressourcen 3

4 Ressourcen Verwaltung Ressourcen-Verwaltung Benutzer konkurrieren um eine begrenzte Menge an Ressourcen Zuteilung (Allocation) Eine begrenzte Menge von Ressourcen wird Benutzern zur Verfügung gestellt Vergabe-Kriterium ist frei / nicht frei Zuteilung der Ressource an irgendeinen Benutzer Einplanung (Scheduling) Eine begrenzte Menge von Ressourcen wird Benutzern zur Verfügung gestellt Vergabe-Kriterium ist: frei / nicht frei plus weitere Eigenschaften der Anfrage und / oder der Ressourcen Zuteilung der Ressource an einen ganz bestimmten Benutzer (Leser-Schreiber, Sonderfall: Zuteilung an Benutzer-Klasse ) 4

5 Ressourcen Verwaltung Ressourcen Verwaltung passive Ressourcen, passiver Verwalter Die Ressourcen und ihr Verwalter sind passiv. Die Kunden die Verwender der Ressource sind aktiv. Verwalter Kunden Ressourcen 5

6 Ressourcen Zuteilung: Zuteiler + passive Ressource 1. request 2. use Kunde Zuteiler (Monitor) 3. release Ressource(n) (offen) SW Struktur: Zuteiler + passive Ressource Zuteiler ist Monitor: Ressourcen sind offen: Nutzungs Protokoll: gemeinsam genutzte Verwaltungsdaten gleichzeitige Nutzung durch viele Kunden das Nutzungsprotokoll (request/use/release) muss eingehalten werden 6

7 Ressourcen Zuteilung Zuteiler: allgemeine Funktionalität request: erwarte Zuteilung möglich teile zu release: gib zurück Zuteiler: Implementierung Monitor (implizite Mutexe / Bedingungsvariablen) explizite Mutexe / Bedingungsvariablen Semaphore 7

8 Ressourcen Zuteilung: Monitor + passive Ressource Zuteiler: Monitor mit Bedingungsvariable (Pseudocode) monitor RessouceAllocator { availcount = countunits; units = set of availableunits; free = new ConditionVariable; Der Zuteiler verwaltet : - Warteschlange der Benutzer plus - Verfügbarkeit der Ressourcen Unit request() { while( avail == 0 ) free.wait(); avail = avail 1; return units.getone(); void release(unit u) { units.insert(u); avail = avail + 1; free.notify(); 8

9 Ressourcen Zuteilung: Monitor + passive Ressource Zuteiler: Realisation mit Mutex und Semaphor (Pseudocode) class RessouceAllocator { avail = countunits; units = set of availableunits; free = Semaphore(countUnits); m = new Mutex; Unit request() { free.down(); m.lock(); avail = avail 1; u = units.getone(); m.unlock(); return u; void release(unit u) { m.lock(); units.insert(u); avail = avail + 1; m.unlock(); free.up(); - Semaphore ist selbst Monitor: geschachtelte Monitore vermeiden! 9

10 Ressourcen Zuteilung: Monitor + passive Ressource gekapselt Zuteiler (Monitor) 3. release use Kunde 2. use Ressource(n) (offen) 10

11 Einplanung Prioritäts basierte Einplanung (Shortest Job Next) Die Ressource wird nach Priorität zugeteilt Priorität: beliebiger ganzzahliger Wert (z.b. Nutzungsdauer) 11

12 Proritäts basierte Einplanung Zuteiler: allgemeine Funktionalität request(p, id): erwarte Zuteilung teile zu release: gib zurück teile zu an den Nutzer mit dem kleinsten p Zuteiler: Implementierung Priorisierte Bedingungsvariable Prioritätswarteschlange Monitor (implizite Mutexe / Bedingungsvariablen) explizite Mutexe / Bedingungsvariablen Semaphore 12

13 Prioritäts basierte Einplanung Prioritäts basierte Einplanung: Implementierung mit priorisierter Bedingungsvariable in einem Monitor (Pseudocode) monitor ShortestJobNext { free = true; turn = new PriorityConditionVariable; request(prio) { if( free ) free = false; else turn.wait(prio); release() { if ( turn.size()==0 ) free = true; else free.signal(); Lösung mit Bedingungsvariable mit Prioritäten: - wait(prio) reiht den ausführenden Thread entsprechend prio in die Warteschlange ein. - signal() reaktiviert den Thread mit der höchsten Priorität. - size() liefert die Anzahl der wartenden Threads 13

14 Prioritäts basierte Einplanung Prioritäts basierte Einplanung: Implementierung mit privaten Semaphoren und Mutex (Pseudocode) class ShortestJobNext { free = true; p = {; sem = new Map(id ~> Semaphore(0)); m = new Mutex(); // Warter als Paare (prio, id) // Semaphor pro id request(prio, id) { m.enter(); while(!free ) { p += (prio, id); m.leave(); sem[id].p(): m.enter(); free = false; m.leave(); release(id) { m.enter(); free = true; if (p!= {) { p = p (prio, id) mit prio minimal in p; sem[id].v(); m.leave(); Privater Semaphor: Semaphor zur Verwendung durch einen Prozess. 14

15 Ressourcen Verwaltung Ressourcen Verwaltung aktive Ressourcen 15

16 Interaktion aktiver Objekte aktive Objekte kommunizieren / interagieren über gemeinsam genutzte Monitore (passive Objekte) oder über Kommunikationskanäle call Interaktion über Monitor call receive send Interaktion über Kommunikationskanal receive send Kanal 16

17 Interaktion aktiver Objekte durch Kommunikation Kommunikation aktiver Objekte über Puffer intern: von Thread zu Thread ( innerhalb eines JVM-Exemplars ) Puffergröße > 0 : asynchron Puffergröße = 0 : Rendez-vous / synchron über echte Kommunikationskanäle extern: Von Prozess zu Prozess ( von JVM zu JVM ) Pufferung im Kanal : asynchrone Kommunikation Keine Pufferung im Kanal: synchrone Kommunikation TCP/IP-Kommunikation: asynchron Kommunikation vs. Monitor Puffer sind Monitore / können als Monitore modelliert werden Es ist trotzdem sinnvoll zu unterscheiden: Monitor-Algorithmen Kommunikations-Algorithmen asynchron ( intern / extern ) synchron ( normalerweise nur intern ) 17

18 Interaktion aktiver Objekte über Monitor: Zuteiler A Variante A: Jobübergabe Zuteiler als Monitor zwischen aktiven Kunden und aktiven Ressourcen use gib ab und vergiss! Zuteiler (Monitor) Ressourcen Kunden Zuteiler: getrequest Koordiniert Kunden und Ressourcen Ressourcen: holen sich Arbeit Kunden: nutzen die Ressource, die ihnen der Monitor zuteilt übergeben dabei Auftrag, der von der Ressource selbständig und ohne Rückinformation an Kunden bearbeitet wird. 18

19 Implementierung: Zuteiler A Variante A: Jobübergabe Zuteiler als Monitor zwischen aktiven Kunden und aktiven Ressourcen use gib ab und vergiss! Zuteiler (Monitor) getrequest Ressourcen Kunden Implementierung: Produzent / Konsument Zuteiler ist Puffer Job put get Kunden Ressourcen Job 19

20 Interaktion aktiver Objekte über Monitor: Zuteiler B Variante B: mit Rückmeldung Zuteiler als Monitor zwischen aktiven Kunden und gib ab und warte! aktiven Ressourcen use getrequest Zuteiler (Monitor) finished Kunden Zuteiler: Ressourcen Koordiniert Kunden und Ressourcen Ressourcen: holen sich Arbeit (getrequest) und informieren Monitor (finished), wenn die Arbeit beendet ist Kunden: geben Arbeit an die Ressource ab, die ihnen der Monitor zuteilt, schlafen bis Nutzung beendet 20

21 Implementierung Zuteiler B Zuteiler als Monitor zwischen aktiven Kunden und Variante B: mit Rückmeldung gib ab und warte! aktiven Ressourcen use Kunden getrequest Zuteiler (Monitor) finished Ressourcen Implementierung: Bedingungssynchronisation im Zuteiler: Formuliere Methoden mit den Voraussetzungen ihres (Weiter ) Arbeitens! 21

22 Implementierung Zuteiler B monitor RessourceAllocaterB { var InfoIn; // Eingabedaten eines Jobs var InfoOUT; // Ausgabedaten eines Jobs Result use(jobinfo){ // Aufruf durch Kunden warte auf freie Ressource speichere JobInfo in InfoIN warte auf Ende der Bearbeitung return InfoOUT JobInfo getrequest() { // Aufruf durch Ressource warte auf Kundschaft nimm nächsten Kunden warte auf JobInfo gefüllt return JobInfo void finished(resultinfo) { // Aufruf durch Ressource speichere resultinfo in InfoOut warte bis Kunde InfoOut gelesen hat Zwei Begegnungen im Zuteiler: - Auftrag abgeben, - Resultat abholen mehrere komplexe Bedingungen auf die gewartet werden muss. Lösung mit expliziten Bedingungs-Variablen. 22

23 Interaktion aktiver Objekte über Monitor: Zuteiler C Variante C: mit Handle des Kunden Zuteiler als Monitor zwischen aktiven Kunden und aktiven Ressourcen use ready Zuteiler (Monitor) Kunden Zuteiler: Ressourcen Koordiniert Kunden und Ressourcen Ressourcen: signalisieren Bereitschaft (ready) und informieren Kunden über Handle, wenn die Arbeit beendet ist Kunden: übergeben Auftrag und Handle an Zuteiler, werden von Ressource informiert (über Handle) wenn die Arbeit beendet ist. 23

24 Implementierung Zuteiler C Variante C: mit Handle des Kunden Zuteiler als Monitor zwischen aktiven Kunden und aktiven Ressourcen use ready Zuteiler (Monitor) Kunden Ressourcen 24

25 Interaktion aktiver Objekte über Monitor: Zuteiler D Variante D: Mit Handle der Ressource Zuteiler als Monitor zwischen aktiven Kunden und aktiven Ressourcen: Komm.-Handle ready use Zuteiler (Monitor) Ressourcen Kunden Zuteiler: Koordiniert Kunden und Ressourcen Ressourcen: signalisieren dem Zuteiler Bereitschaft (ready) und geben dabei Komm.-Handle ab Kunden: fordern Ressource vom Zuteiler, dieser teilt zu, indem er ein Handle der Ressource liefert. Kunde und Ressource kommunizieren via Handle bis die Nutzung beendet ist 25

26 Implementierung Zuteiler D Variante D: mit Handle der Ressource Zuteiler als Monitor zwischen aktiven Kunden und aktiven Ressourcen use ready Zuteiler (Monitor) Kunden Ressourcen 26

27 Ressourcen Verwaltung Ressourcen Verwaltung aktiver Verwalter 27

28 Aktive Zuteiler Zuteiler als aktives Objekt (Thread) zwischen aktiven Kunden und aktiven Ressourcen Kunden 1. request 2. reply Ressourcen Zuteiler Variante A: passive Ressource Zuteiler als aktiver Monitor 28

29 Aktive Zuteiler Zuteiler als aktives Objekt (Thread) zwischen aktiven Kunden und aktiven Ressourcen 3. startuse 4. finish Kunden 5. release Ressourcen 1. request 2. grant Zuteiler Variante B Zuteiler verteilt Nutzungsberechtigungen 29

30 Aktive Zuteiler Zuteiler als aktives Objekt (Thread) zwischen aktiven Kunden und aktiven Ressourcen 2. startuse Kunden Ressourcen 1. request 3. finish 4. finish Zuteiler Variante C Zuteiler zwischen Kunden und Ressourcen 30

31 Aktiver Monitor Aktiver Monitor Aktive Zuteiler ist eine Variante des aktiven Monitors Monitor gegenseitiger Ausschluss Methoden mit Nutzungbedingungen realisiert durch Warten auf freien Zutritt + Warten auf Erfülltsein der Nutzungsbedingung Aktiver Monitor Theard / Prozess nimmt Anfragen blockade frei an Bedient sie falls (ansonsten wenn) die entsprechende Nutzungsbedingung erfüllt ist. Teilt Nutzern das Nutzungsergebnis mit 31

32 Aktiver Monitor Zuteiler als aktiver Monitor process Allocater { free = true; pending = new Queue(); do (forever) { receive request() from proc[index] ~> if (free) { free = false; send reply() to proc[index]; else { pending.insert(index); receive release() from proc[index] ~> if (pending.empty()) { free = true; else { index = pending.remove(); send reply() to proc[index]; proc sind die Kunden-Prozesse. pending enthält unbearbeitete Anfragen. Der Nachrichtenaustausch kann beispielsweise über blockierende Warteschlangen erfolgen. 32

33 Aktiver Monitor Monitor ~> Aktiver Monitor allgemein Jeder passive Monitor kann in einen aktiven (Server-) Prozess transformiert werden. Mutex muss nicht emuliert werden Bedingungs-Variablen durch Warteschlangen mit Anfrager-Id simulieren wait: Anfrager-Id in Warteschlange zusammen mit aktuellem Bearbeitungsstand ablegen signal: Anfrage-Id aus der Warteschlange entnehmen und nach Anschluss der laufenden Aktivität die unterbrochene Bearbeitung wieder aufnehmen. 33