Ebook Modern operating systems (3rd edition) Part 1

(BQ) Part 1 book Modern operating systems has contents Introduction, memory management, processes and threads, file systems, input output, file system management and optimization. (BQ) Part 1 book Modern operating systems has contents Introduction, memory management, processes and threads, file systems, input output, file system management and optimization.

MODERN OPERATING SYSTEMS THIRD EDITION Other bestselling titles by Andrew S Tanenbaum Structured Computer Organization, 5th edition This widely read classic, now in its fifth edition, provides the ideal introduction to computer architecture It covers the topic in an easy-to-understand way, bottom up There is a chapter on digital logic for beginners, followed by chapters on microarchitecture, the instruction set architecture level, operating systems, assembly language, and parallel computer architectures THIRD EDITION Computer Networks, 4th edition This best seller, currently in its fourth edition, provides the ideal introduction to today's and tomorrow's networks It explains in detail how modern networks are structured Starting with the physical layer and working up to the application layer, the book covers a vast number of important topics, including wireless communication, fiber optics, data link protocols, Ethernet, routing algorithms, network performance, security, DNS, electronic mail, the World Wide Web, and multimedia The book has especially thorough coverage of TCP/IP and the Internet Operating Systems: Design and Implementation, 3rd edition This popular text on operating systems is the only book covering both the principles of operating systems and their application to a real system All the traditional operating systems topics are covered in detail In addition, the principles are carefully illustrated with MINIX, a free POSIX-based UNIX-like operating system for personal computers Each book contains a free CD-ROM containing the complete MINIX system, including all the source code The source code is listed in an appendix to the book and explained in detail in the text Vrije Universiteit Amsterdam, The Netherlands Distributed Operating Systems, 2nd edition This text covers the fundamental concepts of distributed operating systems Key topics include communication and synchronization, processes and processors, distributed shared memory, distributed file systems, and distributed real-time systems The principles are illustrated using four chapter-long examples: distributed object-based systems, distributed file systems, distributed Web-based systems, and distributed coordination-based systems PEARSON | PEARSON EDUCATION INTERNATIONAL If you purchased this book within the United States or Canada you should be aware that it has been wrongfully imported without the approval of the Publisher or the Author Editorial Director, Computer Science, Engineering, and Advanced Mathematics: Mania J Ho/ton Executive Editor: Tracy Dimkelberger Editorial Assistant: Melinda Haggerty Associate Editor: ReeAnne Davies Senior Managing Editor Scot! Disauno Production Editor: Irwin Zucker Interior design: Andrew S Tanenbaton Typesetting: Andrew S Tanenbaum Art Director: Kenny Beck Art Editor Gregory Dulles Media Editor: David Alick Manufacturing Manager: Alan Fischer Manufacturing Buyer: Lisa McDowell Marketing Manager: Mack Patterson PEARSON © 2009 Pearson Education, Inc Pearson Prentice Hall Pearson Education, Inc Upper Saddle River, NJ 07458 Ail rights reserved No part of this book may be reproduced in any form or by any means, without permission in writing from the publisher Pearson Prentice Hail™ is a trademark of Pearson Education, Inc The author and publisher of this book have used their best efforts in preparing this book These efforts include the development, research, and testing of the theories and programs to determine their effectiveness The author and publisher make no warranty of any kind, expressed or implied, with regard to these programs or the documentation contained in this book The author and publisher shall not be liable in any event for incidental or consequential damages in connection with, or arising out of, the furnishing, performance, or use of these programs Printed in the United States of America 10 ISBN 21 Q-lB-filBMST-L Pearson Education Ltd., London Pearson Education Australia Pty Ltd., Sydney Pearson Education Singapore, Pte Ltd Pearson Education North Asia Ltd., Hong Kong Pearson Education Canada, Inc., Toronto Pearson Educacidn de Mexico, S.A de C.V Pearson Education—Japan, Tokyo Pearson Education Malaysia, Pte Ltd Pearson Education, Inc., Upper Saddle River, New Jersey To Suzanne, Barbara, Marvin, and the memory of Brant and Sweetie % CONTENT!3 xxiv PREFACE INTRODUCTION 1.1 WHAT IS AN OPERATING SYSTEM? 1.1.1 The Operating System as an Extended Machine 1.1.2 The Operating System as a Resource Manager 1.2 HISTORY OF OPERATING SYSTEMS 1.2.1 The First Generation (1945-55) Vacuum Tubes 1.2.2 The Second Generation (1955-65) Transistors and Batch Systems 1.2.3 The Third Generation (1965-1980) ICs and Multiprogramming 10 1.2.4 The Fourth Generation (1980-Present) Personal Computers 13 1.3 COMPUTER HARDWARE REVIEW 17 1.3.1 Processors 17 1.3.2 Memory 21 1.3.3 Disks 24 1.3.4 Tapes 25 1.3.5 I/O Devices 25 1.3.6 Buses 28 1.3.7 Booting the Computer 31 vii viii CONTENTS 1.4 THE OPERATING SYSTEM ZOO 31 1.4.1 Mainframe Operating Systems 32 1.4.2 Server Operating Systems 32 1.4.3 Multiprocessor Operating Systems 32 1.4.4 Personal Computer Operating Systems 33 1.4.5 Handheld Computer Operating Systems 33 1.4.6 Embedded Operating Systems 33 1.4.7 Sensor Node Operating Systems 34 1.4.8 Real-Time Operating Systems 34 1.4.9 Smart Card Operating Systems 35 1.5 OPERATING SYSTEM CONCEPTS 35 1.5.1 Processes 36 1.5.2 Address Spaces 38 1.5.3 Files 38 1.5.4 Input/Output 41 1.5.5 Protection 42 1.5.6 The Shell 42 1.5.7 Ontogeny Recapitulates Phylogeny 44 1.6 SYSTEM CALLS 47 1.6.1 System Calls for Process Management 50 1.6.2 System Calls for File Management 54 1.6.3 System Calls for Directory Management 55 1.6.4 Miscellaneous System Calls 56 1.6.5 The Windows Win32 API 57 1.7 OPERATING SYSTEM STRUCTURE 60 1.7.1 Monolithic Systems 60 1.7.2 Layered Systems 61 1.7.3 Microkernels 62 1.7.4 Client-Server Model 65 1.7.5 Virtual Machines 65 1.7.6 Exokeraels 69 1.8 THE WORLD ACCORDING TO C 70 1.8.1 The C Language 70 1.8.2 Header Files 71 1.8.3 Large Programming Projects 72 1.8.4 The Model of Run Time 73 1.9 RESEARCH ON OPERATING SYSTEMS 74 CONTENTS 1.10 OUTLINE OF THE REST OF THIS BOOK 75 1.11 METRIC UNITS 76 1.12 SUMMARY 77 PROCESSES AND THREADS 2.1 PROCESSES 81 2.1.1 The Process Model 82 2.1.2 Process Creation 84 2.1.3 Process Termination 86 2.1.4 Process Hierarchies 87 2.1.5 Process States 88 2.1.6 Implementation of Processes 89 2.1.7 Modeling Multiprogramming 91 2.2 THREADS 93 2.2.1 Thread Usage 93 2.2.2 The Classical Thread Model 98 2.2.3 POSIX Threads 102 2.2.4 Implementing Threads in User Space 104 2.2.5 Implementing Threads in the Kernel 107 2.2.6 Hybrid Implementations 108 2.2.7 Scheduler Activations 109 2.2.8 Pop-Up Threads 110 2.2.9 Making Single-Threaded Code Multithreaded 112 2.3 INTERPROCESS COMMUNICATION 115 2.3.1 Race Conditions 115 2.3.2 Critical Regions 117 2.3.3 Mutual Exclusion with Busy Waiting 118 2.3.4 Sleep and Wakeup 123 2.3.5 Semaphores 126 2.3.6 Mutexes 128 2.3.7 Monitors 132 2.3.8 Message Passing 138 2.3.9 Barriers 142 CONTENTS CONTENTS X 3.4.9 The WSClock Page Replacement Algorithm 211 3.4.10 Summary of Page Replacement Algorithms 213 2.4 SCHEDULING 143 2.4.1 Introduction to Scheduling 143 2.4.2 Scheduling in Batch Systems 150 2.4.3 Scheduling in Interactive Systems 152 2.4.4 Scheduling in Real-Time Systems 158 2.4.5 Policy versus Mechanism 159 2.4.6 Thread Scheduling 160 3.5 DESIGN ISSUES FOR PAGING SYSTEMS 214 3.5.1 Local versus Global Allocation Policies 214 3.5.2 Load Control 216 3.5.3 Page Size 217 3.5.4 Separate Instruction and Data Spaces 219 3.5.5 Shared Pages 219 3.5.6 Shared Libraries 221 3.5.7 Mapped Files 223 3.5.8 Cleaning Policy 224 3.5.9 Virtual Memory Interface 224 2.5 CLASSICAL IPC PROBLEMS 161 2.5.1 The Dining Philosophers Problem 162 2.5.2 The Readers and Writers Problem 165 2.6 RESEARCH ON PROCESSES AND THREADS 166 2.7 SUMMARY 167 MEMORY MANAGEMENT 3.1 NO MEMORY ABSTRACTION 174 173 3.6 IMPLEMENTATION ISSUES 225 3.6.1 Operating System Involvement with Paging 225 3.6.2 Page Fault Handling 226 3.6.3 Instruction Backup 227 3.6.4 Locking Pages in Memory 228 3.6.5 Backing Store 229 3.6.6 Separation of Policy and Mechanism 231 3.2 A MEMORY ABSTRACTION: ADDRESS SPACES 177 3.2.1 The Notion of an Address Space 178 3.2.2 Swapping 179 3.2.3 Managing Free Memory 182 3.7 SEGMENTATION 232 3.7.1 Implementation of Pure Segmentation 235 3.7.2 Segmentation with Paging: MULTICS 236 3.7.3 Segmentation with Paging: The Intel Pentium 240 3.3 VIRTUAL MEMORY 186 3.3.1 Paging 187 3.3.2 Page Tables 191 3.3.3 Speeding Up Paging 192 3.3.4 Page Tables for Large Memories 196 3.8 RESEARCH ON MEMORY MANAGEMENT 245 3.4 PAGE REPLACEMENT ALGORITHMS 199 3.4.1 The Optimal Page Replacement Algorithm 200 3.4.2 The Not Recently Used Page Replacement Algorithm 201 3.4.3 The First-In, First-Out (FIFO) Page Replacement Algorithm 202 3.4.4 The Second-Chance Page Replacement Algorithm 202 3.9 SUMMARY 246 FILE S Y S T E M S 4.1 FILES 255 4.1.1 Fit.- W-ming 255 3.4.5 The Clock Page Replacement Algorithm 203 4.1.2 F i g g c t u r e 3.4.6 The Least Recently Used (LRU) Page Replacement Algorithm 204 3.4.7 Simulating LRU in Software 205 3.4.8 The Working Set Page Replacement Algorithm 207 4.1.3 F i i ^ ^ w s 257 258 4.1.4 File Access 260 4.1.5 File Attributes 261 CONTENTS xii 4.1.6 File Operations 262 4.1.7 An Example Program Using File System Calls 263 4.2 DIRECTORIES 266 4.2.1 Single-Level Directory Systems 266 4.2.2 Hierarchical Directory Systems 266 4.2.3 Path Names 267 4.2.4 Directory Operations 270 4.3 FILE SYSTEM IMPLEMENTATION 271 4.3.1 File System Layout 271 4.3.2 Implementing Files 272 4.3.3 Implementing Directories 278 4.3.4 Shared Files 281 4.3.5 Log-Structured File Systems 283 4.3.6 Journaling File Systems 285 4.3.7 Virtual File Systems 286 4.4 FILE SYSTEM MANAGEMENT AND OPTIMIZATION 290 4.4.1 Disk Space Management 290 4.4.2 File System Backups 296 4.4.3 File System Consistency 302 4.4.4 File System Performance 305 4.4.5 Defragmenting Disks 309 4.5 EXAMPLE FILE SYSTEMS 310 4.5.1 CD-ROM File Systems 310 4.5.2 The MS-DOS File System 316 4.5.3 The UNIX V7 File System 319 CONTENTS 5.1.3 Memory-Mapped I/O 330 5.1.4 Direct Memory Access (DMA) 334 5.1.5 Interrupts Revisited 337 5.2 PRINCIPLES OF I/O SOFTWARE 341 5.2.1 Goals of the I/O Software 341 5.2.2 Programmed I/O 342 5.2.3 Interrupt-Driven I/O 344 5.2.4 I/O Using DMA 345 5.3 I/O SOFTWARE LAYERS 346 5.3.1 Interrupt Handlers 346 5.3.2 Device Drivers 347 5.3.3 Device-Independent I/O Software 351 5.3.4 User-Space I/O Software 357 5.4 DISKS 358 5.4.1 Disk Hardware 359 5.4.2 Disk Formatting 374 5.4.3 Disk Arm Scheduling Algorithms 377 5.4.4 Error Handling 380 5.4.5 Stable Storage 383 5.5 CLOCKS 386 5.5.1 Clock Hardware 386 5.5.2 Clock Software 388 5.5.3 Soft Timers 391 4.6 RESEARCH ON FILE SYSTEMS 322 5.6 USER INTERFACES: KEYBOARD, MOUSE, MONITOR 392 5.6.1 Input Software 392 5.6.2 Output Software 397 4.7 SUMMARY 322 5.7 THIN CLIENTS 413 INPUT/OUTPUT 5.1 PRINCIPLES OF I/O HARDWARE 327 5.1.1 I/O Devices 328 5.1.2 Device Controllers 329 5.8 POWER MANAGEMENT 415 5.8.1 Hardware Issues 416 5.8.2 Operating System Issues 417 5.8.3 Application Program Issues 422 5.9 RESEARCH ON INPUT/OUTPUT 423 5.10 SUMMARY 424 Xiv CONTENTS CONTENTS DEADLOCKS 6.1 RESOURCES 432 6.1.1 Preemptable and Nonpreemptable Resources 432 6.1.2 Resource Acquisition 433 6.2 INTRODUCTION TO DEADLOCKS 435 6.2.1 Conditions for Resource Deadlocks 436 6.2.2 Deadlock Modeling 436 6.3 THE OSTRICH ALGORITHM 439 6.4 DEADLOCK DETECTION AND RECOVERY 440 6.4.1 Deadlock Detection with One Resource of Each Type 440 6.4.2 Deadlock Detection with Multiple Resources of Each Type 6.4.3 Recovery from Deadlock 445 MULTIMEDIA O P E R A T I N G S Y S T E M S 7.1 INTRODUCTION TO MULTIMEDIA 466 7.2 MULTIMEDIA FILES 470 7.2.1 Video Encoding 471 7.2.2 Audio Encoding 474 7.3 VIDEO COMPRESSION 476 7.3.1 The JPEG Standard 476 7.3.2 The MPEG Standard 479 7.4 AUDIO COMPRESSION 482 7.5 MULTIMEDIA PROCESS SCHEDULING 485 7.5.1 Scheduling Homogeneous Processes 486 7.5.2 General Real-Time Scheduling 486 7.5.3 Rate Monotonic Scheduling 488 7.5.4 Earliest Deadline First Scheduling 489 6.5 DEADLOCK AVOIDANCE 446 6.5.1 Resource Trajectories 447 6.5.2 Safe and Unsafe States 448 6.5.3 The Banker's Algorithm for a Single Resource 449 6.5.4 The Banker's Algorithm for Multiple Resources 450 7.6 MULTIMEDIA FILE SYSTEM PARADIGMS 491 7.6.1 VCR Control Functions 492 7.6.2 Near Video on Demand 494 7.6.3 Near Video on Demand with VCR Functions 496 6.6 DEADLOCK PREVENTION 452 6.6.1 Attacking the Mutual Exclusion Condition 452 6.6.2 Attacking the Hold and Wait Condition 453 6.6.3 Attacking the No Preemption Condition 453 6.6.4 Attacking the Circular Wait Condition 454 7.7 FILE PLACEMENT 497 7.7.1 Placing a File on a Single Disk 498 7.7.2 Two Alternative File Organization Strategies 499 7.7.3 Placing Files for Near Video on Demand 502 7.7.4 Placing Multiple Files on a Single Disk 504 7.7.5 Placing Files on Multiple Disks 506 6.7 OTHER ISSUES 455 6.7.1 Two-Phase Locking 455 6.7.2 Communication Deadlocks 456 6.7.3 Livelock 457 6.7.4 Starvation 459 6.8 RESEARCH ON DEADLOCKS 459 6.9 SUMMARY 460 7.8 CACHING 508 7.8.1 Block Caching 509 7.8.2 File Caching 510 7.9 DISK SCHEDULING FOR MULTIMEDIA 511 7.9.1 Static Disk Scheduling 511 7.9.2 Dynamic Disk Scheduling 513 7.10 RESEARCH ON MULTIMEDIA 514 7.11 SUMMARY 515 xvi CONTENTS CONTENTS MULTIPLE P R O C E S S O R S Y S T E M S 8.1 MULTIPROCESSORS 524 8.1.1 Multiprocessor Hardware 524 8.1.2 Multiprocessor Operating System Types 532 8.1.3 Multiprocessor Synchronization 536 8.1.4 Multiprocessor Scheduling 540 8.2 MULTICOMPUTERS 546 8.2.1 Multicomputer Hardware 547 8.2.2 Low-Level Communication Software 551 8.2.3 User-Level Communication Software 553 8.2.4 Remote Procedure Call 556 8.2.5 Distributed Shared Memory 558 8.2.6 Multicomputer Scheduling 563 8.2.7 Load Balancing 563 8.3 VIRTUALIZATION 566 8.3.1 Requirements for Virtualization 568 8.3.2 Type I Hypervisors 569 8.3.3 Type Hypervisors 570 8.3.4 Paravirtualization 572 8.3.5 Memory Virtualization 574 8.3.6 I/O Virtualization 576 8.3.7 Virtual Appliances 577 8.3.8 Virtual Machines on Multicore CPUs 577 8.3.9 Licensing Issues 578 8.4 DISTRIBUTED SYSTEMS 578 8.4.1 Network Hardware 581 8.4.2 Network Services and Protocols 584 8.4.3 Document-Based Middleware 588 8.4.4 File-System-Based Middleware 589 8.4.5 Object-Based Middleware 594 8.4.6 Coordination-Based Middleware 596 8.4.7 Grids 601 8.5 RESEARCH ON MULTIPLE PROCESSOR SYSTEMS 602 8.6 SUMMARY 603 521 SECURITY 9.1 THE SECURITY ENVIRONMENT 611 9.1.1 Threats 611 9.1.2 Intruders 613 9.1.3 Accidental Data Loss 614 9.2 BASICS OF CRYPTOGRAPHY 614 9.2.1 Secret-Key Cryptography 615 9.2.2 Public-Key Cryptography 616 9.2.3 One-Way Functions 617 9.2.4 Digital Signatures 617 9.2.5 Trusted Platform Module 619 9.3 PROTECTION MECHANISMS 620 9.3.1 Protection Domains 620 9.3.2 Access Control Lists 622 9.3.3 Capabilities 625 9.3.4 Trusted Systems 628 9.3.5 Trusted Computing Base 629 9.3.6 Formal Models of Secure Systems 630 9.3.7 Multilevel Security 632 9.3.8 Covert Channels 635 9.4 AUTHENTICATION 639 9.4.1 Authentication Using Passwords 640 9.4.2 Authentication Using a Physical Object 649 9.4.3 Authentication Using Biometrics 651 9.5 INSIDER ATTACKS 654 9.5.1 Logic Bombs 654 9.5.2 Trap Doors 655 9.5.3 Login Spooling 656 9.6 EXPLOITING CODE BUGS 657 9.6.1 Buffer Overflow Attacks 658 9.6.2 Format String Attacks 660 9.6.3 Return to libc Attacks 662 9.6.4 Integer Overflow Attacks 663 9.6.5 Code Injection Attacks 664 9.6.6 Privilege Escalation Attacks 665 xviii CONTENTS CONTENTS 9.7 MALWARE 665 9.7.1 Trojan Horses 668 9.7.2 Viruses 670 9.7.3 Worms 680 9.7.4 Spyware 682 9.7.5 Rootkits 686 10.3 PROCESSES IN LINUX 735 10.3.1 Fundamental Concepts 735 10.3.2 Process Management System Calls in Linux 737 10.3.3 Implementation of Processes and Threads in Linux 741 10.3.4 Scheduling in Linux 748 10.3.5 Booting Linux 751 9.8 DEFENSES 690 10.4 MEMORY MANAGEMENT IN LINUX 754 10.4.1 Fundamental Concepts 754 10.4.2 Memory Management System Calls in Linux 757 10.4.3 Implementation of Memory Management in Linux 758 10.4.4 Paging in Linux 764 9.8.1 Firewalls 691 9.8.2 Antivirus and Anti-Antivirus Techniques 693 9.8.3 Code Signing 699 9.8.4 Jailing 700 9.8.5 Model-Based Intrusion Detection 701 9.8.6 Encapsulating Mobile Code 703 9.8.7 Java Security 707 | § 9.9 RESEARCH ON SECURITY 709 9.10 SUMMARY 710 | H v I 10 CASE STUDY 1: LINUX 10.1 HISTORY OF UNIX AND LINUX 716 10.1.1 UNICS 716 10.1.2 PDP-11 UNIX 717 10.1.3 Portable UNIX 718 10.1.4 Berkeley UNIX 719 10.1.5 Standard UNIX 720 10.1.6 MINTX 721 10.1.7 Linux 722 715 f | § J I 10.2 OVERVIEW OF LINUX 724 10.2.1 Linux Goals 725 10.2.2 Interfaces to Linux 726 10.2.3 The Shell 727 10.5 INPUT/OUTPUT IN LINUX 767 10.5.1 Fundamental Concepts 768 10.5.2 Networking 769 10.5.3 Input/Output System Calls in Linux 771 10.5.4 Implementation of Input/Output in Linux 771 10.5.5 Modules in Linux 775 10.6 THE LINUX FILE SYSTEM 775 10.6.1 Fundamental Concepts 776 10.6.2 File System Calls in Linux 781 10.6.3 Implementation of the Linux File System 784 10.6.4 NFS: The Network File System 792 10.7 SECURITY IN LINUX 799 10.7.1 Fundamental Concepts 799 10.7.2 Security System Calls in Linux 801 10.7.3 Implementation of Security in Linux 802 10.8 SUMMARY 802 11 CASE STUDY 2: WINDOWS VISTA 11.1 HISTORY OF WINDOWS VISTA 809 11.1.1 1980s: MS-DOS 810 U.1.2 1990s: MS-DOS-based Windows 811 iU.32000s:NT-basedWmdows 11.1.4 Windows Vista 814 10.2.5 Kernel Structure 732 xix Ml 809 DEADLOCKS 434 CHAP These semaphores are all initialized to Mutexes can be used equally well The three steps listed above are then implemented as a down on the semaphore to acquire the resource, using the resource, and finally an up on the resource to release it These steps are shown in Fig 6-l(a) typedef int semaphore; semaphore resource_1; typedef int semaphore; semaphore resource _ ; semaphore resource_2; void process_A(void) { down(&resource_l); use_resource_t(); up(&resource_l); void process_A(void} { down(&resource_1); down(&resource_2); use_both_resources(); up(&resource_2); up(&resource_1); } (b) } (a) Figure 6-1 Using a semaphore to :t resources, (a) One resource, (b) Two resources SEC 6.2 INTRODUCTION TO DEADLOCKS typedef int semaphore; semaphore resource_ 1; semaphore resource_2; semaphore resource _ 1; semaphore resource_2; void process_A(void) { down(&resource_1); down(&resource _2); use_both„resources(); up(&resource_2); up(&resource_1); } void process_A(void) { down(&resource_1); down(&resource_2); use_botruresources(); up(&resource_2); up(&resource_ 1); J void process.B(void) { down(&resource„1); down(&resource_2); ' use_both_resources(); up(&resource_2); up(&resource_1); } void process_B(void) { down(&resource_2); down(&resource_1); use_both_resources(); up(&resource_1); up(&resource_2); } (a) Sometimes processes need two or more resources They can be acquired sequentially, as shown in Fig 6-l(b) If more than two resources are needed, they are just acquired one after another So far, so good As long as only one process is involved, everything works fine Of course, with only one process, there is no need to formally acquire resources, since there is no competition for them Now let us consider a situation with two processes, A and B, and two resources Two scenarios are depicted in Fig 6-2 In Fig 6-2(a), both processes ask for the resources in the same order In Fig 6-2(b), they ask»for them in a different order This difference may seem minor, but it is not In Fig 6-2(a), one of the processes will acquire the first resource before the other one That process will then successfully acquire the second resource and its work If the other process attempts to acquire resource before it has been released, the other process will simply block until it becomes available In Fig 6-2(b), the situation is different It might happen that one of the processes acquires both resources and effectively blocks out the other process until it is done However, it might also happen that process A acquires resource and process B acquires resource Each one will now block when trying to acquire the other one Neither process will ever run again This situation is a deadlock Here we see how what appears to be a minor difference in coding style— which resource to acquire first—turns out to make the difference between the program working and the program failing in a hard-to-detect way Because deadlocks can occur so easily, a lot of research has gone into ways to deal with them This chapter discusses deadlocks in detail and what can be done about them 435 (b) Figure 6-2 (a) Deadlock-free code, (b) Code with a potential deadlock 6.2 I N T R O D U C T I O N T O D E A D L O C K S Deadlock can be defined formally as follows; A set of processes is deadlocked if each process in the set is waiting for an event that only another process in the set can cause Because all the processes are waiting, none of them will ever cause any of the events that could wake up any of the other members of the set, and all the processes continue to wait forever For this model, we assume that processes have only a single thread and that there are no interrupts possible to wake up a blocked process The no-interrupts condition is needed to prevent an otherwise deadlocked process from being awakened by, say, an alarm, and then causing events that release other processes in the set In most cases, the event that each process is waiting for is the release of some resource currently possessed by another member of the set In other words, each member of the set of deadlocked processes is waiting for a resource that is owned by a deadlocked process None of the processes can run, none of them can release any resources, and none of them can be awakened The number of processes and the number and kind of resources possessed and requested are unimportant This result holds for any kind of resource, including both hardware and software This kind of deadlock is called a resource deadlock It is probably the most common kind, but it is not the only kind We first study resource deadlocks in detail and then return to other kinds of deadlocks briefly at the end of the chapter DEADLOCKS 436 CHAP SEC 6.2 INTRODUCTION TO DEADLOCKS 437 6.2.1 Conditions for Resource Deadlocks Coffman et al (1971) showed that four conditions must hold for there to be a (resource) deadlock: Mutual exclusion condition Each resource is either currently assigned to exactly one process or is available Hold and wait condition Processes currently holding resources that were granted earlier can request new resources No preemption condition Resources previously granted cannot be forcibly taken away from a process They must be explicitly released by the process holding them Circular wait condition There must be a circular chain of two or more processes, each of which is waiting for a resource held by the next member of the chain All four of these conditions must be present for a resource deadlock to occur If one of them is absent, no resource deadlock is possible It is worth noting that each condition relates to a policy that a system can have or not have Can a given resource be assigned to more than one process at once? Can a process hold a resource and ask for another? Can resources be preempted? Can circular waits exist? Later on we will see how deadlocks can be attacked by trying to negate some of these conditions 6.2.2 Deadlock Modeling Holt (1972) showed how these four conditions can be modeled using directed graphs The graphs have two kinds of nodes: processes, shpwn as circles, and resources, shown as squares A directed arc from a resource node (square) to a process node (circle) means that the resource has previously been requested by, granted to, and is currently held by that process In Fig 6-3(a), resource R is currently assigned to process A A directed arc from a process to a resource means that the process is currently blocked waiting for that resource In Fig 6-3(b), process B is waiting for resource S In Fig 6-3(c) we see a deadlock: process C is waiting for resource T, which is currently held by process D Process D is not about to release resource T because it is waiting for resource U, held by C Both processes will wait forever A cycle in the graph means that there is a deadlock involving the processes and resources in the cycle (assuming that there is one resource of each kind) In this example, the cycle is C-T-D-U-C Now let us look at an example of how resource graphs can be used Imagine that we have three processes, A, B, and C, and three resources, R, S, and T The (b) Figure 6-3 Resource allocation graphs, (a) Holding a resource, (b) Requesting a resource, (c) Deadlock requests and releases of the three processes are given in Fig 6-4(a)-(c) The operating system is free to run any unblocked process at any instant, so it could decide to run A until A finished all its work, then run B to completion, and finally run C This ordering does not lead to any deadlocks (because there is no competition for resources) but it also has no parallelism at all In addition to requesting and releasing resources, processes compute and I/O When the processes are run sequentially, there is no possibility that while one process is waiting for I/O, another can use the CPU Thus running the processes strictly sequentially may not be optimal On the other hand, if none of the processes does any I/O at all, shortest job first is better than round robin, so under some circumstances running all processes sequentially may be the best way Let us now suppose that the processes both I/O and computing, so that round robin is a reasonable scheduling algorithm The resource requests might occur in the order of Fig 6-4(d) If these six requests are carried out in that order, the six resulting resource graphs are shown in Fig 6-4(e)-(j) After request has been made, A blocks waiting for S, as shown in Fig 6-4(h) In the next two steps B and C also block, ultimately leading to a cycle and the deadlock of Fig 6-4(j) However, as we have already mentioned, the operating system is not required to run the processes in any special order In particular, if granting a particular request might lead to deadlock, the operating system can simply suspend the process without granting the request (i.e., just not schedule the process) until it is safe In Fig 6-4, if the operating system knew about the impending deadlock, it could suspend B instead of granting it S By running only A and C, we would get the requests and releases of Fig 6-4(k) instead of Fig 6-4(d) This sequence leads to the resource graphs of Fig 6-4(l)-(q), which not lead to deadlock After step (q), process B can be granted S because A is finished and C has everything it needs Even if B should eventually block when requesting T, no deadlock can occur B will just wait until C is finished CHAP DEADLOCKS 438 A requests R B requests S C requests T A requests S B requests T C requests R deadlock * A Request R Request S Release R Release S Request S Request! Release S Release T C Request T Request R Release! Release R (a) (b) (c) © © © ©0© ®®© (f) (g) INTRODUCTION TO DEADLOCKS 439 Later in this chapter we will study a detailed algorithm for making allocation decisions that not lead to deadlock For the moment, the point to understand is that resource graphs are a tool that let us see if a given request/release sequence leads to deadlock We just carry out the requests and releases step by step, and after every step check the graph to see if it contains any cycles If so, we have a deadlock; if not, there is no deadlock Although our treatment of resource graphs has been for the case of a single resource of each type, resource graphs can also be generalized to handle multiple resources of the same type (Holt, 1972) In general, four strategies are used for dealing with deadlocks Just ignore the problem Maybe if you ignore it, it will ignore you (e) (d) SEC 6.2 Detection and recovery Let deadlocks occur, detect them, and take action Dynamic avoidance by careful resource allocation Prevention, by structurally negating*one of the four required conditions We will examine each of these methods in turn in the next four sections 6.3 THE OSTRICH ALGORITHM A requests R C requests T A requests S C requests R A releases R A releases S no deadlock ©©© ©©© m (m) (n) © © i"S AJ m Current allocation matrix Request matrix 2m W Row n is current allocation to process n °n2 "R „3 -• R, Row is what process needs An important invariant holds for these four data structures In particular, every resource is either allocated or is available This observation means that ZCij+Aj^Ej /=! * In other words, if we add up all the instances of the resource / that have been allocated and to this add all the instances that are available, the result is the number of instances of that resource class that exist The deadlock detection algorithm is based on comparing vectors Let us define the relation A < B on two vectors A and B to mean that each element of A is less than or equal to the corresponding element of B Mathematically, A