Chapter 8 Multiple Processor Systems. 8.1 Multiprocessors 8.2 Multicomputers 8.3 Distributed systems

Transkript

1 Chapter 8 Multiple Processor Systems 8.1 Multiprocessors 8.2 Multicomputers 8.3 Distributed systems

2 Multiprocessor Systems Continuous need for faster computers shared memory model message passing multiprocessor wide area distributed system

3 Multiprocessors Definition: A computer system in which two or more CPUs share full access to a common RAM

4 Multiprocessor Hardware (1) Bus-based multiprocessors 4

5 Multiprocessor Hardware (2) UMA Multiprocessor using a crossbar switch

6 Multiprocessor Hardware (3) UMA multiprocessors using multistage switching networks can be built from 2x2 switches (a) 2x2 switch (b) Message format

7 Multiprocessor Hardware (4) Omega Switching Network

8 Multiprocessor Hardware (5) NUMA Multiprocessor Characteristics 1. Single address space visible to all CPUs 2. Access to remote memory via commands - LOAD - STORE 3. Access to remote memory slower than to local

9 Multiprocessor Hardware (6) (a) 256-node directory based multiprocessor (b) Fields of 32-bit memory address (c) Directory at node 36

10 Multiprocessor OS Types (1) Bus Jede CPU hat ein eigenes BS

11 Multiprocessor OS Types (1) Unterteilung des HS in n (hier =4)Partitionen Jede CPU hat eigenen Speicher und Kopie des BS Optimierung: BS-Code liegt nur einmal im Speicher und wird von allen CPUs genutzt n CPUs arbeiten eigentlich nur wie n unabhängige Computer, aber: gemeinsamer Zugriff auf Datenträger und Ein-/Ausgabegeräte flexible Nutzung des gemeinsamen Speichers Effektive Kommunikation über den gemeinsamen Speicher, (Erzeuger schreibt Daten dierekt in den Puffer des Verbrauchers)

12 Multiprocessor OS Types (1) Primitiver Ansatz mit Nachteilen Jedes BS hat seine eigenen Tabellen es kann keinen Lastausgleich (load ballance) geben. D.h.: meldet sich ein Benutzer an einem Knoten an, starten alle seine weiteren Prozesse auf der selben CPU Speicher wird gemeinsam genutzt aber nicht dynamisch verteilt, deshalb kann leicht eintreten: Knoten n hat nichts zu tun und freien Speicher Knoten m braucht zusätzlichen Speicher und muss deshalb Seiten auslagern Puffer-Caches von Plattenspeicherblöcken werden von jedem Knoten unabhängig gehalten und können modifiziert werden Cacheinkonsistenz

13 Multiprocessor OS Types (Master Slave) Fazit: das Modell ist historisch überholt: stammt aus Anfangszeit der Multiprozessorsysteme war eine einfache Möglichkeit, BS schnell für Multiprozessoren anzupassen

14 Multiprocessor OS Types (Master Slave) Bus Master-Slave Multiprozessoren

15 Multiprocessor OS Types (Master Slave) BS und seine Tabellen gibt es nur einmal (nur auf einem Knoten) Alle Systemaufrufe werden zu CPU 1 umgeleitet Löst viele Probleme des alten Modells Lastausgleich (load ballance) für CPU-Auslastung ist möglich Speicherzuteilung kann dynamisch erfolgen Master wird leicht zum Flaschenhals (bei 10% Systemaufrufe ist der Master ab 10 CPUs ausgelasten) Nur für Systeme mit wenig Knoten geeignet

16 Multiprocessor OS Types (SMP) Bus Symmetrische Multiprocessoren

17 Multiprocessor OS Types (SMP) Beseitigt Asymmetrie von Master-Slave Modell Jede CPU kann in den BS-Kern eintreten Balanciert Prozesse und Speicher dynamsich aus (globale BS-Tabellen vorhanden) Konflikte: Zwei CPUs treten gleichzeitig in den BS-Kern ein und beanspruchen gleiche Resourcen (Speicherseite etc.) Setzen eines Mutex beim Eintritt in BS-Kern zur Sequentialisierung der BS-Funktionen löst Konflikt, aber: ist fast so schlecht wie das Master-Slave Modell, denn: bei 10% Systemaufrufe und mehr als zehn CPUs wächst die Zahl der inaktiven, wartenden CPUs

18 Multiprocessor OS Types (SMP) Vermeidung der Wartezeiten durch massive Anpassungen der BSe: Aufteilung der BS-Komponenten in unabhängige kritische Regionen wie Schedular, Dateisystem, Seitenfehlerbehandlung etc: Jede kritische Region ist durch ihren eigenen Mutex geschützt erlaubt höheren Parallelitätsgrad Aber: Resourcen können in mehreren kritischen Bereichen benötigt werden (z.b. Prozesstabelle vom Schedular, der Forck-Funktion und der Signalbehandlung) Jede Tabelle, die von mehreren BS-Funktionen benutzt wird, muss mit einem eigenen Mutex geschützt werden. Dieser muss von jeder Funktion richtig benutzt werden (Gefahr von Deadlocks)

19 Multiprocessor Synchronization (1) Aus Kapitel 2 im Einprozessorumfeld bekannt: Schutz des kritischen Bereichs durch Sperrung von Interrupts atomare TSL-Anweisungen Im Multiprozessorbetrieb ist TSL nicht ausreichend! Lösungen: Hardware: TSL so implementieren, dass er den Bus blockiert. Erfordert spezielle Busfunktionen, die nicht von jedem Bus erfüllt werden. TSL ist aktives Warten (Spinlock)

20 Multiprocessor Synchronization (1) Software -Petersons Protokoll (1981) Verwendung der Cache-Kohärenz Mechanismen (z.b. MESI-Protokoll mit Snoopy Logic): Ist Variable x mit TSL (als Mutex) von CPU 1 gelockt und CPU 2 liest die mit TSL x (=1) in den Cache, so wird CPU 2 informiert, wenn CPU 1 den Wert von x verändert (freigibt) nicht praktikabel, führt zu Casche-Flattern wegen Größe der Cache Lines Lesen ob der Mutex gerade frei ist nein: wieder aktiv warten durch einfaches Lesen ja: TSL ausführen Vorteil: TSL wird seltener ausgeführt und damit das Cache-Flattern vermieden sonst wie oben (CPU1 gibt frei und alle anderen Caches werden ungültig und werden neu gelesen)

21 Multiprocessor Synchronization (2) Einsatz von mehreren Sperren zur Vermeidung von Cache-Flattern

22 Multiprocessor Synchronization (3) Aktives Warten (Spinning) versus Prozessumschaltung (Switching) Soll ein Prozess aktiv auf einen Mutex warten oder sollte das BS zwischendurch einen anderen Prozess/Thread aktivieren? (Problem gibt es nicht bei Einprozessorsystemen - bekommt ein Thread einen Lock nicht, sollte das BS den Thread arbeiten lassen, der den Lock freigeben kann) Manchmal geht Umschalten nicht: Ist beispielsweise die Prozesstabelle gesperrt, kann der Schedular keinen anderen Prozess aktivieren Andernfalls gibt es die Wahl Teufel und Belzebub Aktives Warten benötigt unproduktive CPU Zyklen Umschalten benötigt CPU Zyklen für:

23 Multiprocessor Synchronization (3) Umschalten benötigt CPU Zyklen für: CPU sichert Zustand des aktuellen Threads BS fordert Sperre für Liste der Rechenbereiten Prozesse Schedular muss einen Thread auswählen dessen Zustand laden und starten Cache Blöcke der CPU sind wahrscheinlich ungültig und müssen teuer nachgeladen werden TLB der MMU ist ungültig und muss teuer nachgeladen werden. Irgendwann wird wieder zurückgeschaltet mit den gleichen Kosten Ist es nicht besser, aktiv zu warten? kommt drarauf an, wielange gewartet werden muss. war Gegenstand der Forschung bis 1991 Varianten, falls ein Mutex nicht zugeteilt werden kann: Thread wartet aktiv eine definierte Zeit, erst danach wird umgeschaltet BS protokolliert alle Wartezeiten und benutzt sie bei der Entscheidung

24 Multiprocessor Scheduling (1) Timesharing note use of single data structure for scheduling

25 Multiprocessor Scheduling (2) Space sharing multiple threads at same time across multiple CPUs

26 Multiprocessor Scheduling (3) Problem with communication between two threads both belong to process A both running out of phase

27 Multiprocessor Scheduling (4) Solution: Gang Scheduling 1. Groups of related threads scheduled as a unit (a gang) 2. All members of gang run simultaneously on different timeshared CPUs 3. All gang members start and end time slices together

28 Multiprocessor Scheduling (5) Gang Scheduling

29 Multicomputers Definition: Tightly-coupled CPUs that do not share memory Also known as cluster computers clusters of workstations (COWs)

30 Multicomputer Hardware (1) Interconnection topologies (a) single switch (b) ring (c) grid (d) double torus (e) cube (f) hypercube

31 Multicomputer Hardware (2) Switching scheme store-and-forward packet switching

32 Multicomputer Hardware (3) Network interface boards in a multicomputer

33 Low-Level Communication Software (1) If several processes running on node need network access to send packets Map interface board to all process that need it If kernel needs access to network Use two network boards one to user space, one to kernel

34 Low-Level Communication Software (2) Node to Network Interface Communication Use send & receive rings coordinates main CPU with on-board CPU

35 User Level Communication Software Minimum services provided send and receive commands (a) Blocking send call These are blocking (synchronous) calls (b) Nonblocking send call

36 Remote Procedure Call (1) Steps in making a remote procedure call the stubs are shaded gray

37 Remote Procedure Call (2) Implementation Issues Cannot pass pointers call by reference becomes copy-restore (but might fail) Weakly typed languages client stub cannot determine size Not always possible to determine parameter types Cannot use global variables may get moved to remote machine

38 Distributed Shared Memory (1) Note layers where it can be implemented hardware operating system user-level software

39 Distributed Shared Memory (2) Replication (a) Pages distributed on 4 machines (b) CPU 0 reads page 10 (c) CPU 1 reads page 10

40 Distributed Shared Memory (3) False Sharing Must also achieve sequential consistency

41 Multicomputer Scheduling Load Balancing (1) Process Graph-theoretic deterministic algorithm

42 Load Balancing (2) Sender-initiated distributed heuristic algorithm overloaded sender

43 Load Balancing (3) Receiver-initiated distributed heuristic algorithm under loaded receiver

44 Distributed Systems (1) Comparison of three kinds of multiple CPU systems

45 Distributed Systems (2) Achieving uniformity with middleware

46 Network Hardware (1) Computer (a) (b) Ethernet (a) classic Ethernet (b) switched Ethernet

47 Network Hardware (2) The Internet

48 Network Services and Protocols (1) Network Services

49 Network Services and Protocols (2) Internet Protocol Transmission Control Protocol Interaction of protocols

50 Document-Based Middleware (1) The Web a big directed graph of documents

51 Document-Based Middleware (2) How the browser gets a page 1. Asks DNS for IP address 2. DNS replies with IP address 3. Browser makes connection 4. Sends request for specified page 5. Server sends file 6. TCP connection released 7. Browser displays text 8. Browser fetches, displays images

52 File System-Based Middleware (1) (a) (b) Transfer Models (a) upload/download model (b) remote access model

53 File System-Based Middleware (2) Naming Transparency (b) Clients have same view of file system (c) Alternatively, clients with different view

54 File System-Based Middleware (3) Semantics of File sharing (a) single processor gives sequential consistency (b) distributed system may return obsolete value

55 File System-Based Middleware (4) AFS Andrew File System workstations grouped into cells note position of venus and vice Client's view

56 Shared Object-Based Middleware (1) Main elements of CORBA based system Common Object Request Broker Architecture

57 Shared Object-Based Middleware (2) Scaling to large systems replicated objects flexibility Globe designed to scale to a billion users a trillion objects around the world

58 Shared Object-Based Middleware (3) Globe structured object

59 Shared Object-Based Middleware (4) A distributed shared object in Globe can have its state copied on multiple computers at once

60 Shared Object-Based Middleware (5) Internal structure of a Globe object

61 Coordination-Based Middleware (1) Linda independent processes communicate via abstract tuple space Tuple like a structure in C, record in Pascal 1. Operations: out, in, read, eval

62 Coordination-Based Middleware (2) Publish-Subscribe architecture

63 Coordination-Based Middleware (3) Jini - based on Linda model devices plugged into a network offer, use services Jini Methods 1. read 2. write 3. take 4. notify