William Stallings，拥有美国麻省理工学院计算机科学博士学位和圣母大学电子工程学士学位，现任教于澳大利亚新南威尔士大学国防学院（堪培拉）信息技术与电子工程系。他是世界知名计算机学者和畅销教材作者，已经撰写了17部著作，出版了42本书籍，内容涉及计算机安全、计算机网络和计算机体系结构等方面，曾11次荣获美国“教材和学术专著作者协会”颁发的“年度最佳计算机科学教材”奖。
内页插图
目录
Chapter 1 Operating System Overview 1.1 Operating System Objectives and Functions 1.2 The Evolution of Operating Systems 1.3 MajorAchievements 1.4 Developments Leading to Modern Operating Systems 1.5 Virtual Machines 1.6 OS Design Considerations for Multiprocessor and Multicore 1.7 Microsoft Windows Overview 1.8 TraditionaIUNIX Systems 1.9 Modern UNIX Systems 1.10 Linux 1.11 Linux VServer Virtual Machine Architecture 1.12 Recommended Reading and Web Sites 1.13 Key Terms， Review Questions， and Ptoblems
Chapter 2 ProcessDescription and Control 2.1 What Is a Process? 2.2 Process States 2.3 Process Description 2.4 Process Control 2.5 Execution ofthe Operating System 2.6 Security Issues 2.7 UNIX SVR4 Process Management 2.8 Summary 2.9 RecommendedReading 2.10 Key Terms， Review Questions， and Problems
Chapter 3 Threads 3.1 Ptocesses and Threads 3.2 Types ofThreads 3.3 Multicore and Multithreading 3.4 Windows 7 Thread and SMP Management 3.5 Solaris Thread and SMP Management 3.6 Linux Process and Thread Management 3.7 Mac OS X Grand CentralDispatc 3.8 Summary 3.9 RecommendedReading 3.10 Key Terms， Review Questions， and Problems
Chapter 4 Concurrency： Mutual Exclu- sion and Synchronization 4.1 Principles ofConcurrency 4.2 Mutual Exclusion： Hardware Support 4.3 Semaphores 4.4 Monitors 4.5 Message Passing 4.6 Readers/Writers Problem 4.7 Summary 4.8 RecommendedReading 4.9 Key Terms， Review Questions， and Problems
Chapter 5 Concurrency：Deadlock and Starvatio 5.1 Principles ofDeadlock 5.2 Deadlock Prevention 5.3 Deadlock Avoidance 5.4 Deadlock Detection 5.5 Anlntegrated Deadlock Strategy 5.6 Dining Philosophers Problem 5.7 UNIX Concurrency Mechanisms 5.8 Linux Kernel Concurrency Mechanisms 5.9 Solaris Thread Synchronization Primitives 5.10 Windows 7 Concurrency Mechanisms 5.11 Summary 5.12 RecommendedReading 5.13 Key Terms， Review Questions， and Problems
Polymorphism： Internally， Windows uses a common set of API functions to manipulate objects of any type; this is a feature of polymorphism， as defined in Appendix D. However， Windows is not completely polymorphic because there are many APIs that are specific to a single object type.The reader unfamiliar with object-oriented concepts should review Appendix D. Not all entities in Windows are objects. Objects are used in cases where data are intended for user mode access or when data access is shared or restricted. Among the entities represented by objects are files， processes， threads， semaphores， timers， and graphical windows. Windows creates and manages all types of objects in a uniform way， via the object manager. The object manager is responsible for creat- ing and destroying objects on behalf of applications and for granting access to an object's services and data. Each object within the Executive， sometimes referred to as a kernel object （to distinguish from user-level objects not of concern to the Executive）， exists as a memory block allocated by the kernel and is directly accessible only by kernel mode components. Some elements of the data structure （e.g.， object name， security parameters， usage count） are common to all object types， while other elements are specific to a particular object type （e.g.， a thread object's priority）. Because these object data structures are in the part of each process's address space accessible only by the kernel， it is impossible for an application to reference these data structures and read or write them directly. Instead， applications manipulate objects indirectly through the set of object manipulation functions supported by the Executive. When an object is created， the application that requested the creation receives back a handle for the object. In essence， a handle is an index into a per-process Executive table containing a pointer to the referenced object. This handle can then be used by any thread within the same process to invoke Win32 functions that work with objects， or can be duplicated into other processes. Objects may have security information associated with them， in the form of a Security Descriptor （SD）. This security information can be used to restrict access to the object based on contents of a token object which describes a par- ticular user. For example， a process may create a named semaphore object with the intent that only certain users should be able to open and use that semaphore. The SD for the semaphore object can list those users that are allowed （or denied） access to the semaphore object along with the sort of. access permitted （read， write， change， etc.）. In Windows， objects may be either named or unnamed. When a process creates an unnamed object， the object manager returns a handle to that object， and the handle is the only way to refer to it. Handles can be inherited by child processes， or duplicated between processes. Named objects are also given a name that other unrelated processes can use to obtain a handle to the object. ……
