Betriebssysteme Organisatorisches Vorlesung Dienstags, 10.00 bis 11.30, F55 Übung TradiHonell oder alternahv? Master- Veranstaltung Klausur Februar 2014 InformaHonen hpp://tamdhu.uni- trier.de/asysob studip (c) Peter Sturm, Uni Trier 1
VON MONOLITHEN UND MIKROKERNEN (c) Peter Sturm, Uni Trier 2
Way to Access OS FuncHonality Library funchons Classical procedure call StaHc and dynamic linking System Calls The actual funchons of the operahng systems Wrappers let system calls look like library funchons In some OS, system calls are not directly accessible by applicahons (even as wrappers) Operating System Applications Libraries System Call Wrapper System Calls System Call The only legihmate access to the operahng system kernel System calls = sozware interrupt Code execuhon starts at defined address of associated interrupt service rouhne Switch to privileged mode Switch to kernel stack System Call Illicit Calls Protective Barrier Operating System Sanctum J (c) Peter Sturm, Uni Trier 3
Supervisor Mode & User Mode Modern operahng systems require CPU to differ between Supervisor mode Every instruchon can be executed, including configuring MMU etc. Access to all memory locahons User mode Sensible instruchons are not allowed (MMU, interrupt handling, ) Restricted memory access (MMU) Only OS allowed to run in supervisor mode Hardware Interrupt User Mode Supervisor Mode SoZware Interrupt Switch On Everything Is Inside The Kernel Thread issuing system call stays inside kernel unhl call is completed All required funchonality must be inside kernel Context- switch in case of blocking Monolith System Call OS Kernel (c) Peter Sturm, Uni Trier 4
or ISS Next to Nothing Inside Kernel Microkernel Client Server 1 Server 2 Server 3 Context Switch Server 4 (c) Peter Sturm, Uni Trier 5
Microkernel Implements very few essenhal abstrachons CommunicaHon primihves to cross address spaces ProtecHon Interrupt preprocessing and delivery Goal: No single applicahon can monopolize resources DislocaHon of all remaining operahng system funchonality into user mode server File server CommunicaHon server Graphics server From a scienhfic point of view the most aprachve soluhon Comparison Monolith Pro Fast Contra Keeping a good architecture and structure requires a lot of self- discipline No isolahon between different parts of kernel Hard to extend Complex to adapt Microkernel and Server Pro Good architecture and structure possible Easier to extend Easier to adapt Debugging of servers with user mode tools Contra Slow (too many context switches) (c) Peter Sturm, Uni Trier 6
AcceleraHng Microkernels Sensible and/or Hme- crihcal servers return into kernel Microkernel becomes shll structured monolith RealizaHon AddiHonal linking step replaces IPC with funchons calls Of course, no protechon anymore Server 1 Server n Applied in most modern an microkernel- based operahng systems MACH NT and subsequent systems Microkernel Improving Monoliths Example Linux IntroducHon of a module concept Parts of operahng systems (especially drivers) will be loaded on demand Most modules can be unloaded again ExecuHon, teshng, and debugging shll not possible in user mode SHll no protechon Module 1 Module 2 Module 3 Module n Monolith (c) Peter Sturm, Uni Trier 7
LINUX Linux System Call Interface Process Management Memory Management Filesystems Device Control Networking Architecture Dependent Code Memory Manager Filesystem Types Block Devices Character Devices Network Subsystem IF Drivers (c) Peter Sturm, Uni Trier 8
History Archetype MINIX Minimal- UNIX for teaching purposes A. Tanenbaum, Amsterdam Linus Torvalds implements his own system First appearance: comp.os.minix, 29.3.1991 Hello everybody, I ve had minix for a week now, and have upgraded to 386- minix (nice), and duly downloaded gcc for minix. Yes, it works but ophmizing isnt t working, giving error message [ ]. Is this normal? A minix clone was born Hello everybody out there using minix I m doing a (free) operahng system (just a hobby, won t be big and professional like gnu) for 386(486) AT clones. This has been brewing since April, and is starhng to get ready. I d like any feedback on things people like/dislike in minx, as my OS resembles it somewhat (same phyiscal layout of the file- system (due to prachcal reasons) among other things). I ll get something prachcal within a few months, and i d like to know what features most people would want. Any suggeshons are welcome, but i won t promise I ll implement them :- ) (c) Peter Sturm, Uni Trier 9
Chronology Version 0.01, September 1991 Version 0.11, December 1991 0.11+VM over christmas Version 0.12, January 1992 Increasing number of interested people Quarrel on OS architecture with A. Tanenbaum (Linux is obsolete) Version 0.95, March1992 We are approaching version 1 0.95a, 0.95a.1, 0.95c, 0.95c+, pre0.96, 0.96a (Mai 1992), 0.96b, 0.96b.2, 0.98, 0.98.2, 0.99, 0.99.13, 0.99.13k, Version 1.0, 13. March 1994 Linux is obsolete (1) Tanenbaum I was in the U.S. for a couple of weeks, so i haven t commented much on LINUX (not that i would have said much had i been around), but for what it is worth, i have a couple of comments now. As most of you know, for me MINIX is a hobby, something that i do in the evening when i get bored wrihng books and there are no major wars, revoluhons, and senate hearings being televised live on CNN. My real job is a professor and researcher in the area of operahng systems. As a result of my occupahon, I think I know a bit about where operahng systems are going in the next decade or so. Two aspects stand out [kernel architecture and portability]. [ ] (c) Peter Sturm, Uni Trier 10
Linux is obsolete (2) Tanenbaum (contd.) While I could go into a long story here about the relahve merits of the two designs, suffice to say that among the people who actually design operahng systems, the debate is essenhally over. Microkernels have won. LINUX is a monolithic style system. This is a giant step back into the 1970s. That is like taking an exishng, working C program and rewrihng it in BASIC. I think it is a gross errot to design an OS for any specific architecture, since that is not going to be around all that long. MINIX was designed to be reasonably portable, and has been ported from Intel line to the 680x0 (Atari, Amiga, Macintosh), SPARC, and NS32016. LINUX is Hed fairly closely to the 80x86. Not the way to go. Linux is obsolete (3) Torvalds reply Well, with a subject like this, I m afraid I ll have to reply. Apologies to minix- users who have heard enough about linux anyway. I d linke to be able to just ignore the bait, but Time for some serious flamefeshng! [ ] Look at who makes money off minix, and who gives linux out for free. Then talk about hobbies. Make minix freely available, and one of my biggest gripes with it will disappear. [ ] (Bezugnehmend auf Tanenbaums Beruf) That s one hell of good excuse for some of the brain damages of minix. I can only hope (and assume) that Amoeba doesn t suck like minix does. (c) Peter Sturm, Uni Trier 11
Linux is obsolete (4) Torvalds reply (contd) PS. I apologize for somehmes sounding too harsh: minix is nice enough if you have nothing else. Amoeba might be nice if you have 5-10 spare 386 s lying around, but I certainly don t. I don t usually get into flames, but I m touchy when it comes to linux :) Linux is obsolete (5) Torvalds email next day I wrote: Well, with a subject like this, I m afraid I ll have to reply. And reply I did, with complete abandon, and no thought for good taste and nehquene. Apologies to [Andrew Tanenbaum], and thanks to John Nall for a friendy that s not how it s done lener. I overreacted, and am now composing a (much less acerbic) personal lener to [Andrew Tanenbaum]. Hope nobody was turned away from linux due to it being (a) possibly obsolete (I shll think that s not the case, although some of the crihcisms are valid) and (b) wrinen by a hothead :- ) Linus my first, and hopefully last flamefest Torvalds (c) Peter Sturm, Uni Trier 12
Linux is obsolete (6) Wise words by somebody else Many if not most of the soqware we us is probably obsolete according to the latest design criteria. Most users could probably care less if the internals of the operahng system they use is obsolete. They are rightly more interested in ist performance and capabilihes at the user level. I would generally agree the microkernels are probably the wave of the future. However, it is in my opinion easier to implement a monolithic kernel. It is also easier for it to turn into a mess in a hurry as it is modified. Regards, Ken Ken Thompson, Inventor of UNIX Linux is obsolete (7) The fight is over Tanenbaum I shll maintain the point that designing a monolithic kernel in 1991 is a fundamental error. Be thankful your are not my student. You would not get a high grade for such a design :- ) [ ] WriHng a new OS only for the 386 in 1991 get you your second F for this term. But if you do real well on the final exam, you can shll pass the course. Torvald Well, I probably won t get too good grades even without you: I had an argument (completely unrelated not even pertaining to OS s) with the person here at the university that teaches OS design. I wonder when I ll learn :) (c) Peter Sturm, Uni Trier 13
THE UNIX ROOTS In the beginning 1969: First UNIX version (Bell Labs) Private research project by Ken Thompson to use an otherwise idle PDP- 7 Dennis Richie: C programming language Sources available to universihes from the very beginning Predecessors MULTICS: AmbiHous goal at Bell Labs was archetype for many of the central abstrachons such as file system, shell, etc. CTSS (MIT) GENIE (Berkeley): fork() (c) Peter Sturm, Uni Trier 14
Dennis Ritchie PDP- 11 Ken Thompson 1972 The UNIX Way UNIX was programmed with high- level programming language Triumphal procession for programming language C About 3% assembler only UNIX was distributed as sources AT&T (Bell Labs) had no commerical interest (at first) UNIX featured propertes only much larger and more expensive systems offered at this Hme UNIX provides many elementary funchons that can be combined in very different ways (synergy) fork and pipes (c) Peter Sturm, Uni Trier 15
Important UNIX families First EdiHon up to Tenth EdiHon, Plan 9 The official Bell Labs branch Plan 9 (4th edihon available since 2003) BSD branch Advancements in an academic environment System V Advancements in a commerical environment SunOS / Solaris Linux BSD family First EdiHon Sixth EdiHon Early branch in academia University of Berkeley, San Diego IntegraHon of TCP/IP protocol stack ARPANET Socket API TCP variants (Reno, Tahoe, Vegas, ) License difficulty Several approaches to provide license/free version (Lite x) FreeBSD 3BSD 4.0BSD 4.1BSD 4.2BSD 4.3BSD Tahoe NET/1 Reno NET/2 4.4BSD 4.4BSD Lite 1 1BSD 2BSD 2.8BSD 2.11BSD BSDI 1 FreeBSD 2.0 4.4BSD Lite 2 BSDI 2 (c) Peter Sturm, Uni Trier 16
System V Seventh EdiHon PWB 3.0.1 System III Commercial version Demerger of AT&T (1985) inhibits successful markehng Important improvement Copy- On- Write System V IPC Shared Memory UNIX Streams Semaphores, etc. System V System V Release 2 System V Release 3 System V Release 4 PWB 5.2 Eight EdiHon 4.2 BSD SunOS 3 XENIX Novell UNIX Ware Solaris 2 SunOS / Solaris 4.1c BSD SunOS UNIX branch of SUN Microsystems ConsolidaHon of BSD and System V branches Also available for PC System V Release 4 SunOS 3 SunOS 4 4.3 BSD Solaris Solaris 2 (c) Peter Sturm, Uni Trier 17
MACH KERNEL History Famous microkernel approach starhng 1984 Richard Rashid, CMU, previously working on the Accent network operahng system kernel, now head of MicrosoZ Research Microkernel to cope with the ever increasing complexity of the UNIX operahng system Reduce the number of features in the kernel to make it less complex Mach kernel implements processor and memory management File system, networking, I/O in a user- level Mach task (c) Peter Sturm, Uni Trier 18
Mach AbstracHons Task Container for all the resource of one or more threads Includes virtual memory, ports, processors, Thread Basic unit of execuhon Port In- kernel message queue with capabilihes Message CollecHon of data sent between threads in different tasks using ports Memory Object Container of data mapped into a task s address space Mach Monoliths or Microkernels Monoliths due to performance issues (Mach 2 and 2.5) BSD, OSF/1, NEXTSTEP, OPENSTEP True Microkernel with version 3 Started at CMU, conhnued by OSF Kernel preemphon and RT scheduling Low- level devices represented as ports System- Call redirechon (handling in user space) ConHnuaHons (threads may block by specifying a funchon to be called upon complehon) (c) Peter Sturm, Uni Trier 19
MAC OS X Roots Quite complex history (see Singh for details) OS Kernel NuKernel first, replaced by Mach kernel later OS Personality Various approaches including TalOS, Copland, Gershwin, BeOS, NEXTSTEP and OPENSTEP (with Sun Microsystems) and ObjecHve- C Final products Mac OS 8 and 9 Rapsody (1997) Various user interfaces with Carbon and Cocoa now the most common (c) Peter Sturm, Uni Trier 20
Family Tree FreeBSD NetBSD Mac 3.0 OPENSTEP 4.4 BSD Rapsody 1998 Mac OS Blue Box Mac OS X Server 1.0 March 1999 Mac OS X DP1 May 1999 Darwin 0.1 March 1999 Mac OS X 10.0 March 2001 Mac OS X 10.5 October 2007 Architecture GUI Aqua ApplicaHon Environments Classic, BSD, X11, Carbon, Cocoa, WebObjects, QuickTime, Java (AWT, Swing) Graphics and MulHmedia QuickDraw 2D, Quartz, OpenGL, QuickTime, Audio, JRE Core Services JDK, JVM BSD API (Posix u.a.) Mach Hardware (c) Peter Sturm, Uni Trier 21
MICROSOFT WINDOWS Overview Since Windows NT back in 1989 32 bit and 64 bit operahng systems PreempHve and reentrant scheduling Full virtual memory support Support for mulhprocessor systems IniHal a mikrokernel- based approach with a number of Hme- crihcal services re- integrated into the kernel OS personalihes are implemented as subsystems on top of Windows kernel Windows subsystem common to all (provides Win32 API) Some server systems support POSIX subsystem There was a OS/2 subsystem once (c) Peter Sturm, Uni Trier 22
Overall Architecture Subsystem System Support Processes Service Processes User ApplicaHons Environment Subsystems System Call Interface Subsystem DLLs Kernel ExecuHve Device Drivers Windowing and Graphics Hardware AbstracHon Layer (HAL) Windows ExecuHve System Call Interface System Threads System Service Dispatcher I/O Manager USER GDI File System Cache Object Manager Plug and Play Manager Security Reference Monitor Virtual Memory Processes and Threads Config Manager (Registry) Local Procedure Call Graphics Driver Kernel Hardware Abstraction Layer (HAL) (c) Peter Sturm, Uni Trier 23
Literature D. Bovet, M. CesaH, Understanding the Linux Kernel, 3rd EdiHon, O Reilly, 2006 Eric Levenez, Various chronologies on operahng systems, hpp://www.levenez.com J. Mauro, R. McDougall, Solaris Internals, Sun Microsystems Press, 2001 M.K. McKusik, K. BosHc, M.J. Karels, J.S. Quarterman, The Design and ImplementaHon of the FreeBSD OperaHng System, Addison- Wesley, 2005 G. Moody, rebel code Linux and the Open Source RevoluHon, The Penguin Press, 2001 M.E. Russinovich, D.A. Solomon, Microsoq Windows Internals, 4 th EdiHon, MicrosoZ Press, 2005 Amit Singh, Mac OS X Internals A Systems Approach, Addison- Wesley, 2007 A.S. Tanenbaum, A.S. Woodhull, The Minix Book OperaHng Systems, 3rd EdiHon, PrenHce- Hall, 2006 L. Torvalds, just for fun, Harper Business, 2001 (c) Peter Sturm, Uni Trier 24
System Software Winter 2014 Opera&ng Systems Virtual Machines Virtualisierung System X System X Virtualiza&on Maschine Y is a framework or Maschine Y methodology of dividing the resources of a computer into mul&ple execu&on environments, by applying one or more concepts or technologies such as hardware and soaware par&&oning, &me- sharing, par&al or complete machine simula&on, emula&on, quality of service, and many others. System X Maschine Y =Y VirtualisierungssoAware Maschine Y Amith Singh (c) Peter Sturm, University of Trier, D-54286 Trier, Germany 1
System Software Winter 2014 Vorteile Server- Konsolidierung Testen und Debugging Isola&on Sandboxing Fault / Error Containment Ausführung von Legacy SoAware Alte Anwendungen Alte Betriebssysteme Indirek&onsstufe Migra&on Quality of Service Lastverteilung Administra&on Automa&sierung Schulungen Auslieferungsmedium für Anwendungen Einsichten in neue SoAware Nachteile Zeit- und Platzeffizienz Schlecht virtualisierbare Hardware Bereits im Gast- OS genutzte Virtualisierung (c) Peter Sturm, University of Trier, D-54286 Trier, Germany 2
System Software Winter 2014 Technik ist recht verbreitet! Virtualisierung einzelner Ressourcen Terminal = Window Ak&ves Fenster hat Fokus (=Keyboard und Maus) CPU = Thread Adreßraum Speicher = Virtual Memory Virtualisierung ganzer Rechner 16 Bit Windows und DOS- Anwendungen Ausführung in einer virtuellen Maschine Virtuelle Maschinen unterschiedlichster Bauart Ressourcen- Virtualisierung Bessere Ausnutzung Kontextwechsel bei blockierendem Aufruf Nebenläufige Anwendungen profi&eren von Mul&prozessoren aber laufen auch auf Monoprozessoren Eliminieren von Engpässen Mehr Speicher durch Paging Jede Anwendung bekommt ihr eigenes Terminal Schutz / Isola&on Anwendungen untereinander isoliert Betriebssystem vor defekten/bösar&gen Anwendungen geschützt (c) Peter Sturm, University of Trier, D-54286 Trier, Germany 3
System Software Winter 2014 Beispiel Virtueller Speicher Stack MMU Page Table Virtueller Adreßraum Heap Data Code Abbildungsverfahren Ort jeder genutzten virtuellen Seite im Speicher Mehrwert Isola&on von Adreßräumen Schutz Bessere Speichernutzung Overhead wird durch speziellen Cache (Transla&on Lookaside Buffer) minimiert Realer Adreßraum Historische Wurzeln (c) Peter Sturm, University of Trier, D-54286 Trier, Germany 4
System Software Winter 2014 Details 1959 bis 1970, IBM federführend, aber auch MIT u.a. Geburtsstunde des Mul&- Programming und Time- Sharing Atlas Project, Manchester (1961) Mul&cs, MIT (1963) m44/44x, IBM 704 Serie, CTSS, CP- 40, CP- 67, VM/370 IBM (ca. 1965) Mehrere iden&sche Kopien der Hardware Kommende OS- Genera&on noch zu jung und instabil Schnelle Nutzung der besser werdenden Hardware Etablierte und zuverlässige Betriebssysteme mitels virtuellen Maschinen replizieren Virtualisierungsarten Emula&on Vollständige Simula&on anderer CPU und Hardware Na&ve Virtualisierung (Full Virtualiza&on) Keine Änderung des Gastsystems (=Transparenz) Paravirtualisierung Gastsysteme sind sich ihrer Virtualisierung bewußt Transparenz oberhalb des Gastes OS- Level- Virtualisierung Betriebssystem virtualisiert mehrere Instanzen seiner selbst Anwendungsvirtualisierung (c) Peter Sturm, University of Trier, D-54286 Trier, Germany 5
System Software Winter 2014 Emula&on Interpreta&on MS Virtual PC für PPC Emulatoren für Atari, VC64, Apple II, Übersetzung Roseta (MAC OS X, PPC auf Intel) WOW64 (32 Bit Windows auf Itanium 2) Performanz Na&ve Virtualisierung Befehlssatz Gast = Befehlssatz Host Voraussetzungen Privilegierter und nicht- privilegierter Modus Gut virtualisierbare CPU ;- ) Gast- OS führt privilegierte Instruk&on aus VMM interpre&ert Befehl im Kontext der virtuellen Hardware Wechsel zu virtueller Hardware für Gast- OS unsichtbar Anwendung Nicht- Privilegiert Gast- OS Nicht- Privilegiert Anwendung Virtuelle Nicht- Privilegiert Hardware VMM OS Privilegiert Hardware (c) Peter Sturm, University of Trier, D-54286 Trier, Germany 6
System Software Winter 2014 Typ- 1 und Typ- 2 Type-2 VMM Gast 1 Gast 2 Type-1 VMM (Hypervisor) VMM Gast 1 Gast 2 Host OS Hardware VMM Hardware Beispiele VMware, Parallels,... Fortgeschritene Konzepte Drag and Drop Schnappschüsse Clones Mul&media Virtuelle Rechnernetze MicrosoA Virtual PC und Virtual Server Virtual Box von Sun (c) Peter Sturm, University of Trier, D-54286 Trier, Germany 7
System Software Winter 2014 Kri&sche Instruk&onen Reale CPUs mehr oder weniger gut virtualisierbar x86 eher weniger J Gründe Nicht- privilegierte Instruk&onen geben AuskunA über privilegierte Hardware- Informa&onen (Interrupts, ) Instruk&onsresultat abhängig vom Ausführungsmodus Instruk&onen verändern versteckten Prozessorzustand Insgesamt 17 kri&sche Instruk&onen Ausführung löst keine Excep&on aus Für VMM schwer erkennbar (z.b. aufwendige Filterung) Paravirtualisierung Gast- System muß angepaßt werden Vorteile Für Virtualisierung ungüns&ge Hardware- EigenschaAen abschwächen bzw. auzeben Kri&sche Instruk&onen vermeiden Geringe Effizienzverluste Nachteile Zugang zum Sourcecode notwendig Bedeutendster Vertreter: Xen Starkes Interesse seitens VMware und MicrosoA (c) Peter Sturm, University of Trier, D-54286 Trier, Germany 8
System Software Winter 2014 Xen Host Gast 1 Gast n Dom0 Dom1 Dom n Xen Hypervisor Hardware Open Source Projekt der Universität Cambridge Volle Virtualisierung mit HW- Unterstützung möglich Spezielles Hostsystem in Dom0 stellt in der Regel Treiber für E/A bereit Führt diverse Xen- Prozesse aus Gäste greifen über virtuelle Treiber und Host auf Geräte zu Shared Memory und Events User- Mode Linux (UML) Por&erung des Linux- Kernels auf virtuelle Architektur um arch/um bildet Funk&onalität auf System Calls ab UML besteht aus mehreren Linux- Prozessen Anwendungen Linux Anwendungen arch/um Linux arch/i386 Hardware i386 Hardware um (c) Peter Sturm, University of Trier, D-54286 Trier, Germany 9
System Software Winter 2014 OS- Level Virtualisierung Dünne Virtualisierungsschicht oberhalb des Betriebssystems Jedes Server- OS bietet entsprechende Möglichkeiten Virtual Environments, Virtual Private Servers, Jails, vservers, Zones, Containers, Kommerzielle Lösungen Bemerkungen Leichtgewich&g Vergleichsweise komplex Meist fangen vorgeschaltete Kerneltreiber alle Aufrufe ab Service 1 OS X Service 2 OS X Service 3 OS X Virtualisierungsschicht OS X Hardware Produkte Wikipedia (c) Peter Sturm, University of Trier, D-54286 Trier, Germany 10
System Software Winter 2014 ABI/API- Virtualisierung WINE Windows API auf UNIX/Linux und X CrossOver Kommerzielle Wine- Version SUN WABI Windows Applica&on Binary Interface für x86 Emula&on auf SPARC Applica&on Virtualisierung Viel Ähnlichkeit mit Emula&on, aber keine Nachbildung eines vorhandenen Befehlssatzes sondern eigenständige, problemspezifische Lösung Meist deutlich höhere Abstrak&onen als CPU- Instruk&onen Wich&gste Vertreter Java Virtual Machine (JVM).NET Common Language Run&me (CLR) DIE Laufzeitpla ormen der Gegenwart (c) Peter Sturm, University of Trier, D-54286 Trier, Germany 11
System Software Winter 2014 Beispiele Wikipedia Weitere Beispiele Web- Server Virtual Directory Virtual Host Applica&on Server Enterprise JavaBeans Weitere Indirek&onsstufe WPF und WF aus.net 4.5 Instruk&onssätze XAML XAML Presenta&on XOML (c) Peter Sturm, University of Trier, D-54286 Trier, Germany 12
System Software Winter 2014 MicrosoA Diverse Ansätze seit mindestens 1995 in Benutzung Virtual DOS Machine (VDM) DOS- Anwendungen unter Windows ausführen WOW32, WOW64 Unterstützung für 16- Bit- Anwendungen auf 32- Bit- Windows und 32- Bit- Anwendungen auf 64- Bit- Windows ABI/API- Emula&onen für OS/2 und POSIX Applica&on Virtualiza&on SQL Server, IIS, Exchange Server, Terminal Server,. Aktuelle Produktlinie Ziel: Paravirtualisierte Windows- Betriebssysteme, Hypervisor Windows Enlightenment Paravirtualisierbare Windows- Betriebssysteme Seit Longhorn (Codebase Vista für Server) Verlagerung der Treiber in Gast- OS Virtualiza&on Provider Virtualiza&on Client Direkter HW- Zugang für Gäste Direct3D bzw. DirectX für Gäste zugänglich!!! (c) Peter Sturm, University of Trier, D-54286 Trier, Germany 13
System Software Winter 2014 Sicherheit VMWare SoAware Remote Heap Exploit in vmnat.exe Angreifer kann eine virtuelle Maschine verlassen und Host kompromi}eren Angriffe auf JVM und.net CLR durch Fehler in der Speicherverwaltung S. Govindavajhala, A.W. Appel, Princeton, 2003 Blue Pill Atack Joana Rutkowska, COSEINC Nutzt Hardwareunterstützung für Virtualisierung Malware wird kleiner Hypervisor OS kommt in eine virtuelle Umgebung und wird kontrollierbar Geht On the fly Exploit auf AMD64 SVM über Vista Schutz mit zusätzlicher HW- Unterstützung möglich Authenifizierung auf HW- Ebene beim Einrichten neuer VMs (c) Peter Sturm, University of Trier, D-54286 Trier, Germany 14
System Software Winter 2014 TRENDS Trends Mehr Funk&onalität Migra&on virtueller Maschinen im laufenden Betrieb Konver&erung Aus realer Installa&on wird virtuelle Installa&on Aus virtueller Installa&on wird reale Installa&on Zwischen verschiedenen virtuellen Formaten Mehr Standards Offenlegung der Formate virtueller Festplaten Management komplexer virtueller Infrastrukturen Mehr Hardwareunterstützung Paravirtualisierung bei Hardwaretreibern Zugriff auf 3D- Features moderner Graphikkarten in der virtuellen Maschine Direkter Support in modernen CPUs (c) Peter Sturm, University of Trier, D-54286 Trier, Germany 15
System Software Winter 2014 Visionen?! Virtuelle Maschinen werden immer billiger Ausreichend viele CPUs vorhanden Kompakte Images Snapshots werden als Deltas gespeichert Mehrere VMs nutzen gleiche Codebasis Hypervisor + Virtuelle Maschinen wird Normalfall Wenn der Prophet nicht zum Berg kommt, Betriebssysteme erlauben saubere Anwendungsstrukturen Aber viele Anwendungen werden unsauber realisiert Jede Anwendung bekommt eigene virtuelle Hardware Virtuelle Maschinen werden Einheiten des Deployments Virtuelle Zeiten Anwendungen werden als vorkonfigurierte virtuelle Maschinen ausgeliefert Bessere Isola&on Weniger Wechselwirkungen Erhöhte Flexibilität Erhöhte Mobilität Viele VMs laufen auf jeweils einem Rechner Zeit- und Platzeffizienz Renaissance in Forschung und Entwicklung Virtualisierungstechniken sind neuer alter Trend (c) Peter Sturm, University of Trier, D-54286 Trier, Germany 16
System Software Winter 2014 Trend OnBoard Hypervisor Trend: Hypervisor wandelt sich 1. Genera&on Hosted Typ- 2- Hypervisor Hardware Host Betriebssystem Hypervisor Gast Betriebssystem Applika&on (c) Peter Sturm, University of Trier, D-54286 Trier, Germany 17
System Software Winter 2014 Mehr Typ 1? Na&ve Typ- 1- Hypervisor Hardware Hypervisor Gast Betriebssystem Applika&on Trend Managed Code Hardware Hypervisor Gast Betriebssystem Managed Run&me Environment Applika&on (c) Peter Sturm, University of Trier, D-54286 Trier, Germany 18
System Software Winter 2014 Trend: Gast- OS wandelt sich Beispiel ESX Server 3i Teilmenge der POSIX OS- API VSockets über VMCI (zukünaig) Microkernel++? Canonical JeOS Just Enough Opera&ng System Minimal- Ubuntu für Virtual Appliances Für ESX Server 3i Hypervisor BEA Liquid VM JVM für den Hypervisor Für Virtual Appliances HW HV RTE Applika&on MicrosoA Server Core Konfigurierbarer minimal Windows Server ohne GUI Oder noch schlimmer...... Browser ist das Betriebssystem Vergleichbar JVM oder CLR Beispiel Chrome Trend Rich Internet Applica&ons (RIAs) Aspekt verteilter Systeme Integra&on von Clouds bzw. *aas HW Minimal OS Browser RIA (c) Peter Sturm, University of Trier, D-54286 Trier, Germany 19
System Software Winter 2014 Hardwareunterstützung Support für virtuelle Maschinen Unzulänglichkeiten der x86- Architektur bzgl. Virtualisierung besei&gen Intel VT (früher Vanderpool) AMD V (früher Pacifica) IOMMU Virtuelle Adreßabbildung und Schutz bei DMA- Zugriffen Legacy 32- Bit- Support auf 64- Bit- Systemen Direkter aber geschützter Zugriff virtueller Gäste auf Hardware Direkter aber geschützter Zugriff von Anwendungen augf Hardware Intel VT VM Entry Host- State Area VM Exit Guest- State Area Zwei Realisierungen x86- Architektur: VT- x Itanium: VT- i VM Exits sind konfiguierbar Welche Excep&on soll Exit auslösen? Welcher I/O- Zugriff? Welche maschinenspezifischen Register sind geschützt? Welche kri&schen Instruk&onen? (c) Peter Sturm, University of Trier, D-54286 Trier, Germany 20
System Software Winter 2014 Trend: VM als Einheit des Deployment Open Virtual Machine Format (OVF) Portabel und HV- unabhängig XML- basierter Standard zum Austausch virtueller Maschinen Unterstützt Virtual Appliances / SoAware Appliances Nicht nur Betriebssysteme sondern Applika8onen Virtual Appliances VM- Ensembles als einheitliche Applika&on Beispiel CRM- Applika&on Web Server, Datenbank- Server, Frontend, Jede Komponente eine VM Einfache Installa&on Standards Image Spezifika&onen Interne Repräsenta&on der virtuellen Laufwerke offengelegt VMware MicrosoA Zusammenarbeit bei Defini&on eines Paravirtualisierungs- APIs Windows auf Xen ohne Sourcecode und HW möglich Einheitliche Management- APIs Ums&eg von Apple auf Intel- CPUs hat Szene belebt (c) Peter Sturm, University of Trier, D-54286 Trier, Germany 21
System Software Winter 2014 Record/Replay Komplete Kontrolle der Zeit aus Sicht einer VM Vollkommen determinis&sche Ausführung Einsatzszenarien SoAware- Tests / Debugging Exakte Reproduzierbarkeit von Fehlern Race- Condi&ons Als Log an Entwickler liefern Debugger nachträglich einhängen Consumer Recovery im täglichen Einsatz? VM- basierte Wiederherstellungspunkte? (c) Peter Sturm, University of Trier, D-54286 Trier, Germany 22
Innova@ve Architekturansätze Peter Sturm AG Systemso8ware Betriebssysteme im Umbruch Allgemeine Probleme Steigende Komplexität Mangelnde Zuverlässigkeit Neue Herausforderungen ManyCore- Architekturen Neue Anwendungsszenarien RIAs Managed Applica@ons (c) AG SysSo8, University of Trier 1
Chrome OS + Chromium OS Kategorie Just enough opera@ng system Chromo OS = Google Produkt Chromium OS = Open Source Projekt Applica@ons (JavaScript, RIA,...) Chrome Browser Customiza@on Linux Derivat Microso8 Singularity Forschungsprojekt von Microso8 Research 2004 ~2009 Design Prinzipien Komplecer Neubeginn ( Name J ) Keine Abwärtskompa@bilität Fokus auf Zuverlässigkeit Typsichere Sprachen und So8wareverifika@on Microkernel- Architektur wikipedia (c) AG SysSo8, University of Trier 2
Adressräume Isola@on von Verschiedenen Prozessen Kernel und Prozessen Grund? Unmanaged Code C / C++, Assembler, Nicht typsichere Sprachen Potenziell fehlerha8e Verwendung von Pointern Singularity Ansatz App App Datei- system Treiber TCP/IP Stack CLR CLR CLR CLR CLR GC GC GC GC GC ABI CLR Garbage Collector Kernel (C#) Adressraum Kernel Mode è Keine Wechsel von Adressräumen mehr notwendig! (c) AG SysSo8, University of Trier 3
Alles im gleichen Adressraum! Kernel, Treiber, Applika@onen Isola@on Typsichere Sprache (keine Pointer) Alle Referenzen explizit und typisiert Verifika@on während der Übersetzung Isola@on ist formal beweisbar! Keine Isola@on auf HW- Ebene Nicht notwendig Kein Adressraumwechsel Keine kalten Caches / TLBs, So8ware- isolierte Prozesse (SIPs) è Microkernel- Ansatz wird effizient! So8ware- isolierte Prozesse (SIPs) Verifika@on zur Übersetzungszeit Deshalb (momentan) Keine Code- Generierung zur Laufzeit Kein dynamisch nachgeladener Code (c) AG SysSo8, University of Trier 4
Interprozess Kommunika@on Komplece Isola@on? Interak@on nur über spezielle Kommunika@onskanäle Nachrichtentypen + Abfolge per Kontrakt spezifiziert Compiler überprü8 korrekte Verwendung Abhängigkeiten Vollständig über Kontrakte spezifiziert Zwischen allen SIPs Treiber, Applika@onen, Kernel, Dateisystem, Sing# C#- Dialekt Sing# Kommunika@on und Kontrakte auf Sprachebene Defini@on von Endpunkten Empfang von (mehreren) Nachrichten Senden von Nachrichten Zustandsmodell (c) AG SysSo8, University of Trier 5
public contract TcpConnectionContract { in message Connect(uint dstip, ushort dstport); out message Ready(); } state Start : Ready! -> ReadyState; state ReadyState : one { Connect? -> ConnectResult; BindLocalEndPoint? -> BindResult; Close? -> Closed; } state BindResult : one { OK! -> Bound; InvalidEndPoint! -> ReadyState; } in message Listen(); state Bound : one { Listen? -> ListenResult; Connect? -> ConnectResult; Close? -> Closed; } Technische Umsetzung Effiziente Nachrichtenkommunika@on? App App Datei- system Treiber TCP/IP Stack CLR CLR CLR CLR CLR GC GC GC GC GC ABI CLR Garbage Collector Kernel (C#) Exchange Heap (c) AG SysSo8, University of Trier 6
Exchange Heap Durch Kernel verwaltete Datenstruktur Enthält typisierte Nachrichten Kernel erlaubt und entzieht Zugriff auf Teile des Heaps Austausch einer Nachricht Referenz auf Nachricht an Kernel übergeben Kernel benachrich@gt Empfänger und gibt ihm Referenz auf die Nachricht è Simple Pointer - Opera@on Invariante Zu jedem Zeitpunkt hat nur ein Prozeß eine Referenz auf Teil des Exchange Heaps Verifika@on durch Compiler auf Basis des Kontrakts Composability Aktuelle Betriebssysteme? Welche Auswirkung hat die Installa@on der So8ware X auf die restliche So8ware? Kaum vorhersehbar Ziel Explizite Abhängigkeiten Vorhersagbarkeit von Effekten und Fehlern z.b. bei Fehler in einer Komponente abhängige Komponenten benachrich@gen / neu starten (c) AG SysSo8, University of Trier 7
Performance? Landläufige Meinung In C/C++ geschriebene So8ware läu8 schneller als So8ware, die in C# oder JAVA geschrieben wurden! Auf den zweiten Blick Performancevorteile IPC ohne Kontextwechsel Kernelaufrufe ohne Kontextwechsel Keine Run@me Checks notwendig à Checks einmalig bei der Übersetzung if (ptr!=null) *ptr Benchmark- Ergebnisse Faktor 5 10 schneller als aktuelle Betriebssysteme (FreeBSD, Linux, Windows) (c) AG SysSo8, University of Trier 8
MICROSOFT MIDORI Microso8 Midori Forschungsprototyp mit Praxisbezug Sogenanntes Incuba@on - Projekt Basiert auf Singularity Geheimnisumwicert Spekula@onen Zukün8ige Windows- Version? Bislang wenig technische Details bekannt Trend zu formalen Methoden (c) AG SysSo8, University of Trier 9
Midori Programmiermodell Concurrency Asynchrone OS API Kommunika@on über asynchrone Nachrichten Erlaubt bessere Mul@Core Skalierbarkeit siehe z.b. auch MS Robo@cs Studio Distributed Concurrency Einbeziehung enxernter Komponenten à Cloud Compu@ng Programmiermodell unterstützt Nachrichtenverlust, Latenzen, sporadische Konnek@vität Virtualisierungsaspekte Virtualisierbarkeit des Kernels Na@v ausführbar auf x86, x86 und ARM Ausführung im Hypervisor typsichere Interak@on zwischen Hypervisor und Kernel Ausführung in einem Windows- Prozess (c) AG SysSo8, University of Trier 10
Quellen Ar@kel Galen C. Hunt, James R. Larus, Singularity: Rethinking the So9ware Stack, ACM SIGOPS OperaAng Systems Review, vol. 41, no. 2, pp. 37-49, Apr. 2007 Mark Aiken et al., Deconstruc=ng Process Isola=on, in ACM SIGPLAN Workshop on Memory Systems Performance and Correctness, pp. 1-10, ACM, San Jose, CA, Oct. 2006 Galen Hunt et al., An Overview of the Singularity Project, no. MSR- TR- 2005-135, pp. 44, MicrosoV Research, Oct. 200 Singularity als Source Code und bootbares Image hcp://www.codeplex.com/singularity Channel 9 Videos hcp://channel9.msdn.com Erste Midori- Fakten hcp://www.sd@mes.com/microsoft_s_plans_for_post_windows_os_revealed (c) AG SysSo8, University of Trier 11
Betriebssysteme 4. Synchronisa>on Programming Model Unlimited virtual memory Unlimited number of virtual CPUs Mechanisms to synchronize concurrent threads Way to communicate Between applica>ons on a single host (IPC) Between hosts in a network Persistent storage of informa>on (file system) (c) Peter Sturm, Uni Trier 1
Compe>>on and Coopera>on Compe>>on Applica>ons compete for resources Goal: Sole user of system Implicit Synchroniza>on Virtual resources Serializa>on by OS Mutual exclusion Coopera>on Applica>ons (Threads) cooperate Sharing of resources and tasks Goals Performance improvement Avoidance of botlenecks Fault tolerance Mutual exclusion and more specific synchroniza>on paterns (c) Peter Sturm, Uni Trier 2
How to Avoid the Flaw Enforce Serializa>on Execute each thread one by one No parallelism at all No error, but also no gain in performance Enforce Atomicity Set of instruc>ons can t be interrupted Applica>on- specific Define beginning and end = Cri>cal Sec>on At most 1 thread inside cri>cal sec>on at any >me Mutual exclusion THEREFORE SEMAPHORE (c) Peter Sturm, Uni Trier 3
Semaphore Fundamental synchronization primitive Two basic functions (on a semaphore s) s.p() May block in case semaphore already occupied s.v() Never blocks; releases semaphore and may free a blocked thread Dijkstra (1968), THE Multiprogramming System P = passeren (request entry) V = vrygeven (release) P" Semaphore Semantic Semaphores are counting signals s.p(): Thread waits for some signal s s.v(): Thread sends a signal s Semaphor = Integer (s.value) Initialized with a s.value 0 void P () { s.value--; if (s.value < 0) Block calling thread; } Of course, P and V themselves are cri>cal sec>ons and must be protected! void V () { s.value++; if (s.value < 1) Put a thread waiting in s into ready queue; } (c) Peter Sturm, Uni Trier 4
Implementation S:" value" queue" TCB" TCB" TCB" P Execution of P must be atomic Thread k calls P V Execution of V must be atomic Calling thread normally doesn t block s.value--; if (s.value < 0) { tail(s.queue) := k; block(k); } s.value++; if (s.value <= 0) { ready(head(s.queue)) delhead(s.queue) } Hardware- Related Synchroniza>on Issues Semaphore are High- level blocking synchroniza>on func>onality Provided by the opera>ng system or run>me plaaorm Minimum wai>ng >me in the order of milliseconds Semaphore are not useful for Synchroniza>on issues inside the opera>ng system itself Synchroniza>on in coopera>ng threads on a mul>processor system Op>mal blocking >me in the order of nanoseconds Approaches Disabling interrupts Atomic pairing of read and write access to a single address Spinlocks (busy wai>ng J ) (c) Peter Sturm, Uni Trier 5
DISABLE INTERRUPTS Disable Interrupts When a thread executes a sequence of instruc>ons, it can only be disrupted by an external interrupt Disabling interrupts leads to atomic instruc>on sequences All CPUs offer special instruc>ons Enable Interrupts Interrupts for a given priority level or higher are enabled Disable Interrupts Interrupts for a given priority level and lower are masked Arrival of interrupt is recognized (1 bit latch) Some interrupts can never be masked (NMI = non- maskable interrupt) Disadvantages Affects only a single CPU, so not useful for mul>processor systems No IO devices can be handled while interrupts disabled Disabling interrupts for longer periods of >me is dangerous for real>me systems Not suitable for applica>ons (c) Peter Sturm, Uni Trier 6
Wrong Example Implemen>ng mutual exclusion as the basis for any higher- level synchroniza>on mechanism bool mutex = false; Disable Interrupt DI while Enable (mutex) Interrupt // Busy wait; mutex = true; EI It doesn t work that way? DI while (mutex) // Busy wait; mutex = true; EI // Critical section mutex = false; Thread 1 // Critical section mutex = false; Thread n Correct Example Implemen>ng mutual exclusion as the basis for any higher- level synchroniza>on mechanism bool mutex = false; Loop: DI h = mutex; if (!h) goto Next EI goto Loop Next: mutex = true; EI // Critical section mutex = false; Thread 1 Loop: DI h = mutex; if (!h) goto Next EI goto Loop Next: mutex = true; EI // Critical section mutex = false; Thread n (c) Peter Sturm, Uni Trier 7
Comments Works on a monoprocessor system, but nevertheless not a very sensible solu>on Enabling and disabling interrupts is an expensive instruc>on on many CPUs Interferes with the opera>ng system func>onality Primary use in opera>ng system Avoid data inconsistencies inside the kernel itself by asynchronous >mer and device interrupts SPIN LOCKS (c) Peter Sturm, Uni Trier 8
Atomic Read and Write Cycle Address bus \Valid Address \Read \Write Data bus Read Address Atomic Combined read and write cycle to a single address Not interruptable even on a mul>processor system Write Address All modern CPUs offer such instruc>ons SPARC: LDSTUB (Atomic Load- Store Unsigned Byte), SWAP 680x0: TAS (Test and Set) No privileged instruc>ons required for synchroniza>on Example Using Atomic Test and Set h = TAS Address h := Memory[Address] Memory[Address] := 1 Loop: h = TAS mutex if (h) goto Loop // mutex is now 1 // Critical section mutex = 0; Loop: h = TAS mutex if (h) goto Loop // mutex is now 1 // Critical section mutex = 0; Spinlock Thread 1 Thread n (c) Peter Sturm, Uni Trier 9
Spinlocks Useful only for short wai>ng >me Mutual exclusion on a mul>processor when accessing the scheduling queues Synchronizing on a hardware event happening in the near future Synchroniza>on for coopera>ng threads running on different CPUs Running Ready Blocked Poten>al risks Starva>on, Livelocks, Performance with respect to mul>processors and caching.net Support Class Interlocked in System.Threading static int Increment (ref int x) Increments variable x atomically and returns result static int Decrement (ref int x) Decrements variable x atomically and returns result static int Exchange (ref int x, int y) Assigns value y to variable x atomically and retuns the previous value static int CompareExchange (ref int x, int y, int c) Assigns value y to x atomically iff x == c; returns previous value of x (c) Peter Sturm, Uni Trier 10
Spinlock Example in.net CRITICAL SECTION WITHOUT HELP (c) Peter Sturm, Uni Trier 11
Cri>cal Sec>on A sensible sequence of instruc>ons which may only be executed by one thread at a >me Mutual exclusion required inside cri>cal sec>on Must be defined by the applica>on Bracke>ng by some Enter() and Leave() opera>ons: EnterCriticalSection(); Cri>cal Sec>on Sensible instruction 1; Sensible instruction k; LeaveCriticalSection(); Requirements for Correct Implementa>on 1. Mutual exclusion At any given >me at most one thread is inside 2. No deadlocks Threads are delayed for a finite amount of >me before entering the cri>cal sec>on 3. Fairness Any thread who wants to enter the cri>cal sec>on will enter eventually 4. Efficiency Threads are not delayed needlessly Threads that are currently not interested shouldn t do superfluous work (c) Peter Sturm, Uni Trier 12
Basic Program Structure We assume 2 threads with ids 0 and 1 con>nuously entering the cri>cal sec>on: public void Loop () { DateTime start = DateTime.Now; do { EnterCriticalSection(); threads_inside_critical_section++; if (threads_inside_critical_section > 1) { Console.WriteLine("Oops. More than one thread inside critical section"); } Different Implementa>ons } Thread.Sleep(0); // Forces context switch threads_inside_critical_section--; LeaveCriticalSection(); } while (((TimeSpan)(DateTime.Now - start)).totalseconds < seconds_to_run); Do not make use of any synchroniza>on support No primi>ves provided by the opera>ng system No hardware support Vola>le Data Structures Hardware (CPU, MMU), run>me support, and compiler normally relax memory consistency to improve performance Re- odering memory access as long as program seman>cs are not altered Don t expect memory to change by side- effects Normally, a single thread is assumed Unexpected behavior in mul>- threaded environments Data structures that are accessed concurrently by mul>ple threads should be marked volatile Nobody will cache these data Compiler expects these data to change asynchronously Every access will read the memory address (c) Peter Sturm, Uni Trier 13
Vola>le and C# Specific keyword volatile bool flag Specific sta>c methods in Thread available object Thread.VolatileRead ( ref object ) Thread.VolatileWrite ( ref object, object) Various overloads The problem with arrays: Consider volatile bool [] flags Reference to array is marked vola>le The booleans themselves are not! Thread.VolatileRead() and Thread.VolatileWrite() don t work on boolean Workaround: Integers instead of boolean 1 true Some subsequent examples may look strange L Star>ng Point Empty func>ons to enter and leave the cri>cal sec>on No concurrency control Several threads may be inside cri>cal sec>on in parallel Want to check this non- func>onal version? (c) Peter Sturm, Uni Trier 14
Result Mutual exclusion condi>on invalidated many >mes Step 1: Alterna>ng Token Implemen>ng a token- based approach The thread who owns the token may enter, the other waits The token must circulate among the par>cipa>ng threads Start from scratch 01 Alterna>ng Token Start Inves>gate complete example 01 Alterna>ng Token Final (c) Peter Sturm, Uni Trier 15
Alterna>ng Token For each thread self = own thread rival = rival thread Solu>on private volatile static int turn = 0; public void EnterCriticalSection () { while (turn!= self) /* Busy Wait */; } public void LeaveCriticalSection () { turn = rival; } Result No invalida>on Times inside cri>cal sec>on iden>cal (±1) (c) Peter Sturm, Uni Trier 16
Comments Mutual exclusion is guaranteed It is a fair solu>on Provided any It is a non- blocking solu>on (Busy Wai>ng) Requires preemp>ve scheduling Threads must pass the token ac>vely although they are not interested in entering the cri>cal sec>on Solu>on doesn t consider different interest and enter frequency of all threads involved Step 2: Someone Inside Threads set flag when inside cri>cal sec>on Only enter if the rival is not already inside Start from scratch 02 Someone Inside Start Inves>gate complete example 02 Someone Inside Final (c) Peter Sturm, Uni Trier 17
Someone About to Enter For each thread self = own thread rival = rival thread Solu>on private static bool[] inside = new int[2] { 0, 0 }; public void EnterCriticalSection () { while (inside[rival] == 1) /* Busy Wait */ ; inside[self] = 1; } public void LeaveCriticalSection () { inside[self] = 0; } Result Mutual exclusion condi>on s>ll invalidated several >mes (c) Peter Sturm, Uni Trier 18
Comments Mutual Exclusion not guaranteed Thread 0: inside[0] == 0;... while (inside[1] == 1) ; inside[0] = 1; // Inside Critical Section Context Switch Thread 1: inside[1] == 0;... while (inside[0] == 1) ; inside[1] = 1; // Inside Critical Section Tes>ng and sevng flag is not atomar Gets worse with increasing number of threads Step 3: Set before Test Threads express their interest before they enter the cri>cal sec>on Only enter if the rival is not interested too Start from scratch 03 Set Before Test Start Inves>gate complete example 03 Set Before Test Final (c) Peter Sturm, Uni Trier 19
Set Before Test For each thread self = own thread rival = rival thread Solu>on private static bool[] interested = new int[2] { 0, 0 }; public void EnterCriticalSection () { interested[self] = 1; while (interested[rival] == 1) /* Busy Wait */ ; } public void LeaveCriticalSection () { interested[self] = 0; } Result No progress awer 1 minute! Why? (c) Peter Sturm, Uni Trier 20
Comments Mutual exclusion guaranteed At most one thread (actually 0) inside Livelock Threads are in execu>on But s>ll no progress is made Thread 0: interested[0] = 1; while (interested[1]==1) ; while (interested[1]==1) ; while (interested[1]==1) ; while (interested[1]==1) ; while (interested[1]==1) ;... Context Switch Thread 1: interested[1] = 1; while (interested[0]==1) ; while (interested[0]==1) ; while (interested[0]==1) ; while (interested[0]==1) ; while (interested[0]==1) ;... Step 4: I want, I don t want, I want Trying to avoid livelock In case of imminent livelock release flag for a short period of >me and try again Well, it s s>ll busy wai>ng, but Start from scratch 04 Short Break Start Inves>gate complete example 04 Short Break Final (c) Peter Sturm, Uni Trier 21
Short Break For each thread self = own thread rival = rival thread Solu>on private static bool[] interested = new int[2] { 0, 0 }; public void EnterCriticalSection () { interested[self] = 1; while (interested[rival] == 1) { interested[self] = 0; /* Short Break */; interested[self] = 1; } } public void LeaveCriticalSection () { interested[self] = 0; } Result Seems to work? (c) Peter Sturm, Uni Trier 22
Comments Mutual exclusion guaranteed Mutual Courtesy Threads in lockstep can exhibit livelock- like behavior Thread 0: interested[0] = 1; while (interested[1]==1) interested[0] = 0; /* Short Break */ interested[0] = 1; while (interested[1]==1) interested[0] = 0; /* Short Break */ interested[0] = 1;...c Thread 1: interested[1] = 1; while (interested[0]==1) interested[1] = 0; /* Short Break */ interested[1] = 1; while (interested[0]==1) interested[1] = 0; /* Short Break */ interested[1] = 1;... The Algorithm by Dekker Combina>on of versions 4 and 2 4: Set before test, but avoid livelocks by releasing the own flag again 2: Alterna>ng token to resolve conflicts fair bool [] interested = new bool[2] { false, false }; int turn = 0; EnterCriticalSection () { interested[self] = true; while (interested[rival]) { if (turn == rival) { interested[self] = false; while (turn == rival) /* Busy Wait */ ; interested[self] = true; } } } LeaveCriticalSection () { turn = rival; interested[self] = false; } Want to see it live? (c) Peter Sturm, Uni Trier 23
The Algorithm by Peterson Improvement of Dekkers algorithm Conflict is resolved through race condi>on Who made the last write to turn? bool [] interested = new bool[2] { false, false }; int turn = 0; EnterCriticalSection () { interested[self] = true; turn = rival; // Volatile race condition while (interested[rival] and (turn == rival)) { /* Busy Wait */ ; } } LeaveCriticalSection () { interested[self] = false; } Want to see it live? Conclusions Synchroniza>on problems are hard to solve without addi>onal help High probability for errors Deadlocks Livelocks Starva>on No mutual exclusion et all Vola>le data structures Busy wai>ng in general is a bad solu>on Inside OS kernels some>mes useful (for very short periods of >me) (c) Peter Sturm, Uni Trier 24
MONITOR Language- based Synchroniza>on Semaphores and/or other synchroniza>on primi>ves are sufficient to solve any complex synchroniza>on problem But complex solu>ons are very hard to understand It is nearly impossible to an>cipate any entangled execu>on of concurrent threads and the influence on data consistency Most humans are single- threaded (at least with respect to consciousness J ) High error probability with increasing problem complexity Synchroniza>on techniques with a higher level of abstrac>on are needed One possible solu>on: add synchroniza>on support to programming languages (c) Peter Sturm, Uni Trier 25