nsp5

 Documents

 21 views
of 30
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Description
5 Implementierung von Prozessen und Synchronisationskonstrukten (zur Auffrischung nachlesen: 2.3 ) Prozeß ? Prozessor Daten ? Speicher Def.: Strukturtreue…
Share
Transcript
5 Implementierung von Prozessen und Synchronisationskonstrukten (zur Auffrischung nachlesen: 2.3 ) Prozeß ? Prozessor Daten ? Speicher Def.: Strukturtreue Implementierung:  Mehrprozessorsystem (multiprocessor) mit privaten und gemeinsamen Speichern für private und gemeinsame Variable  Parallele, d.h. echt simultane, Ausführung aller Prozesse Beispiele für nicht strukturtreue Implementierung:  Mehrprozessorsystem ohne private Speicher  alle Daten im zentralen Arbeitsspeicher  Weniger Prozessoren als Prozesse, z.B. Einprozessorsystem  quasi-simultane, verzahnte Ausführung im Mehrprozeßbetrieb (multitasking, multiprogramming)  Mehrrechnersystem ohne gemeinsamen Speicher (multicomputer)  nachrichtenbasierte Prozeßinteraktion 5.1 Mehrprozessorbetrieb ... zunächst betrachtet unter der Voraussetzung:  jeder Prozeß läuft auf einem eigenen Prozessor;  gemeinsame Daten und Synchronisationsobjekte liegen in gemeinsamem Speicher. 5.1.1 Sperrsynchronisation Fragestellung: Wie kann die Sperroperation lock (3.1.5) implementiert werden? monitor Lock {// ! setzt bereits Sperrmechanismus voraus ! private boolean lock = false; public void lock() when !lock { lock = true; } public void unlock() { lock = false; } } Idee: Wiederholt lock prüfen – solange lock gesetzt ist; sobald lock nicht gesetzt ist, selbst setzen. Aber: naive Umsetzung dieser Idee führt nicht zum Erfolg. Hardware bietet Unterstützung: unteilbare Instruktionen Beispiel: Instruktion TAS (test-and-set) für unteilbares Lesen/Schreiben im Arbeitsspeicher boolean TAS(var boolean lock) { < boolean result = lock; lock = true; > return result; } Damit class Lock { private boolean lock = false; public void lock() { while(TAS(lock)) ; } public void unlock() { lock = false; } } Andere unteilbare Operationen ermöglichen ähnliches – z.B. SWAP INC ..... Terminologie: Ein so benutzte Sperrvariable heißt spin lock. Die hier praktizierte Art des Wartens heißt aktives Warten (busy waiting). Aktives Warten ist normalerweise verpönt - weil es Ressourcen verbrät (Prozessor und Speicherzugriffe!). Spin locks werden daher nur auf unterster Ebene für extrem kurzes Sperren eingesetzt, z.B. für die Implementierung von Semaphoren oder Monitoren – nicht explizit im Anwendungs-Code. 5.1.2 Sperren ohne spezielle Instruktionen genauer: nur mit atomarem Lesen bzw. Schreiben natürlicher Zahlen (Dekker, Dijkstra, Habermann, Peterson, .....) n Prozesse Gemeinsame Variable: next = 0,1,...,n-1, anfangs 0 Private Variable: me = Prozeßnummer state = idle, eager, critical, anfangs idle 6 0 me 1 next 5 4 2 3 lock: repeat set eager, wait until all processes from next to me are idle, set critical until nobody else is critical; set next to me. unlock: set next to me  1, set idle. Temporäre Variable:p wait until ...: repeat set p to next, while idle do increment p until p equals me. nobody else ...: set p to me  1, while p is not critical do set p to p  1, 5.1.3 Ereignissynchronisation monitor M { public R op(A a) when C { S } ... } { do { monitor.lock(); if(!C) {monitor.unlock(); continue;} else break; } } while(true); S monitor.unlock(); } mit Sperrvariable monitor Problematisch: geschachteltes aktives Warten, sogar für längere Zeiträume Spezialfall: S leer und C unteilbar, z.B. „Warten bis c != 0“ while(c == 0); (Java: c sollte volatile sein) 5.2 Mehrprozeßbetrieb (multitasking, multiprogramming) Vor.: (zunächst) nur 1 Prozessor Idee: Prozessor ist abwechselnd mit der Ausführung der beteiligten Prozesse befaßt („quasi-simultane“ Ausführung, processor multiplexing) 5.2.1 Koroutinen Subroutinen, Prozeduren, Operationen, Methoden, ..... : Interaktion mit Aufruf/Rücksprung (call/return), d.h. „Übergang“ zwischen Prozeduren bedeutet entweder Aufruf: A-Inkarnation erzeugt B-Inkarnation, übergibt Parameter und springt zum Startpunkt von B oder Rücksprung: Löschen der B-Inkarnation, Rückgabe von Parametern, Rücksprung zur Aufrufstelle in A SUBROUTINE B SUBROUTINE A SUBROUTINE B ... ... ... CALL A CALL B ... ... ... RETURN RETURN RETURN COROUTINE A COROUTINE B ... ... RESUME B ... ... RESUME A RESUME B ... ... RESUME A Beliebig viele Koroutinen können beteiligt sein, z.B. 3 : A RESUME B B RESUME A RESUME C C Koroutine (coroutine) Interaktion mit exchange jump RESUME statt call/return: A: RESUME B bewirkt Sprung von A-Inkarnation nach B-Inkarnation an denjenigen Punkt, an dem die B-Inkarnation das letzte Mal (mit RESUME) verlassen wurde Jede Inkarnation „kennt“ ihren eigenen letzten RESUME-Punkt. Erzeugen/Löschen von Koroutinen-Inkarnationen: verschiedene Varianten möglich, z.B.  erstes RESUME A erzeugt (einzige!) A-Inkarnation;  Ende von A wirkt wie RESUME X , wobei X diejenige Koroutine ist, die A letztmalig am Startpunkt aktiviert hat;  erneutes RESUME A aktiviert A wiederum am Startpunkt. Beispiel-Programm: Programmiersprachen mit Koroutinen : Simula (1967, Dahl/Myhrhaug/Nygaard) Modula (1980, Wirth) u.a. Anwendungen:  Übersetzerbau  Simulation diskreter Ereignisse  Mehrprozeßbetrieb / Threading 5.2.2 Prozesse/Threads als Koroutinen Ansatz:  Prozeß wird durch Koroutine simuliert;  Blockieren nicht als aktives Warten, sondern als exchange jump zu anderer Koroutine: „Prozeßwechsel“, „Prozeßumschaltung“ 3 mögliche (Makro-)Zustände eines Prozesses: aktiv: läuft, „ist im Besitz des Prozessors blockiert: (wartend) wartet auf Ereignis bereit: ist weder aktiv noch blockiert, d.h. ist lauffähig, aber nicht im Besitz des Prozessors Zustandsübergänge z.B. bei Verwendung von Semaphoren: aktiv [P] * * P bereit blockiert [V] (vgl. 2.2.2) [ ] bedeutet: Operation wird durch anderen Prozeß ausgeführt * bedeutet: Entscheidung über Prozessorvergabe erforderlich class Semaphore { // assuming coroutine support static private Coroutine current; // active process static private Queue readyList = new LinkedQueue(); // ready processes private int count; private Queue waitingList = new LinkedQueue(); // blocked processes public Semaphore(int init) {count = init;} public void P() { count--; if(count < 0) { waitingList.add(current); current = readyList.remove(); // leere Bereitliste ? Verklemmung ! resume current; } } public void V() { count++; if(count <= 0) readyList.add(waitingList.remove()); // leere Warteliste ? Nicht möglich ! } } Bemerkungen:  Prozeßwechsel nur bei Blockade (d.h. jede Anweisungsfolge ohne Blockade ist unteilbar – insbesondere auch P und V !)  Daher spin locks weder erforderlich noch korrekt (!) (keine echte Parallelität) w Sowohl Prozessorvergabe als auch Semaphore sind FIFO  Bei Prioritätsteuerung eventuell Prozeßwechsel auch in V (wenn höherrangiger Prozeß geweckt wird) ! Nichtblockierender Prozeß monopolisiert den Prozessor ! () Abhilfe:  Operation yield(), die einen Prozeßwechsel erlaubt  Automatisch erzwungener Prozeßwechsel in regelmäßigen Abständen, mittels Zeitgeber-Unterbrechung (time slicing  round-robin scheduling) 5.3 Java Threading Zur Erinnerung: 2.3 Threads und Synchronisation werden in verschiedenen Java-Systemen verschieden realisiert ! Meist – nicht immer – werden  sowohl die Prioritäten berücksichtigt (4.1)  als auch time slicing praktiziert Wenn kein time slicing, dann Thread.yield() verwenden, um absichtlich den Prozessor an einen anderen bereiten Thread abzugeben (sofern vorhanden) Frohes Fest! [Ende Kap. 5]
Similar documents
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks