《操作系统设计与实现》第3版英文PDF资源

5星 · 超过95%的资源需积分: 50 96 浏览量更新于2024-07-26 3 收藏 14.05MB PDF 举报

"《操作系统设计与实现》是Andrew S. Tanenbaum和Albert S. Woodhull合著的一本经典教材，第三版于2006年由Prentice Hall出版。这本书专注于通过MINIX操作系统来讲解操作系统的设计原理和实现方法。MINIX 3是一个精简且简化的新版本，特别强调高可靠性，适用于嵌入式系统，并便于教学。读者可以通过访问www.minix3.org获取最新版的MINIX和模拟器，以便在其他系统上运行MINIX。" 《操作系统设计与实现》第三版是操作系统领域的权威教材，作者Andrew S. Tanenbaum是Vrije Universiteit Amsterdam的教授，而Albert S. Woodhull来自美国马萨诸塞州的阿默斯特。本书以MINIX操作系统为例，深入浅出地介绍了操作系统的核心概念和技术。MINIX是一个开源的小型操作系统，它的设计和实现方式对理解复杂的操作系统机制具有极高的价值。书中涵盖的内容可能包括但不限于以下几个方面： 1. **操作系统概述**：介绍操作系统的定义、历史和基本功能，解释其在计算机系统中的重要性。 2. **进程管理**：讲解进程的概念、创建、销毁、调度和同步等，以及死锁的预防和处理。 3. **内存管理**：探讨虚拟内存、页面替换算法、内存分配和回收策略等，以确保高效地利用有限的物理内存。 4. **文件系统**：阐述文件的组织结构、I/O操作、文件权限和访问控制，以及磁盘调度算法。 5. **设备管理**：介绍设备驱动程序的作用，以及如何处理I/O请求，包括中断处理和DMA（直接存储器访问）。 6. **网络和通信**：讨论操作系统的网络子系统，包括套接字编程、网络协议栈以及进程间通信机制，如管道、消息队列和共享内存。 7. **安全与稳定性**：分析操作系统安全的重要性，探讨防止攻击和漏洞的方法，以及如何设计高可用性和容错性的系统。 8. **MINIX 3系统架构**：详细解析MINIX 3的设计目标、系统模块化、微内核架构及其对高可靠性和嵌入式应用的适应性。 9. **实践与实验**：提供使用MINIX 3进行实际操作和实验的指导，帮助读者将理论知识转化为实践经验。 10. **最新技术发展**：考虑到技术的快速发展，书中可能还涵盖了新的操作系统发展趋势，如云计算、移动计算和实时操作系统等。通过阅读《操作系统设计与实现》第三版，学习者不仅能掌握操作系统的基本原理，还能了解到实际操作系统设计和实现的细节，这对于软件开发人员、系统管理员以及计算机科学的学生来说都是极其宝贵的知识资源。

[Page 4]

1.1. What Is an Operating System?

Most computer users have had some experience with an operating system, but it is difficult to pin

down precisely what an operating system is. Part of the problem is that operating systems perform

two basically unrelated functions, extending the machine and managing resources, and depending

on who is doing the talking, you hear mostly about one function or the other. Let us now look at

both.

1.1.1. The Operating System as an Extended Machine

As mentioned earlier, the architecture (instruction set, memory organization, I/O, and bus

structure) of most computers at the machine language level is primitive and awkward to program,

especially for input/output. To make this point more concrete, let us briefly look at how floppy disk

I/O is done using the NEC PD765 compatible controller chips used on many Intel-based personal

computers. (Throughout this book we will use the terms "floppy disk" and "diskette"

interchangeably.) The PD765 has 16 commands, each specified by loading between 1 and 9 bytes

into a device register. These commands are for reading and writing data, moving the disk arm, and

formatting tracks, as well as initializing, sensing, resetting, and recalibrating the controller and the

drives.

The most basic commands are read and write, each of which requires 13 parameters, packed into

9 bytes. These parameters specify such items as the address of the disk block to be read, the

number of sectors per track, the recording mode used on the physical medium, the intersector gap

spacing, and what to do with a deleted-data-address-mark. If you do not understand this mumbo

jumbo, do not worry; that is precisely the pointit is rather esoteric. When the operation is

completed, the controller chip returns 23 status and error fields packed into 7 bytes. As if this were

not enough, the floppy disk programmer must also be constantly aware of whether the motor is on

or off. If the motor is off, it must be turned on (with a long startup delay) before data can be read

or written. The motor cannot be left on too long, however, or the floppy disk will wear out. The

programmer is thus forced to deal with the trade-off between long startup delays versus wearing

out floppy disks (and losing the data on them).

Without going into the real details, it should be clear that the average programmer probably does

not want to get too intimately involved with the programming of floppy disks (or hard disks, which

are just as complex and quite different). Instead, what the programmer wants is a simple, high-

level abstraction to deal with. In the case of disks, a typical abstraction would be that the disk

contains a collection of named files. Each file can be opened for reading or writing, then read or

written, and finally closed. Details such as whether or not recording should use modified frequency

modulation and what the current state of the motor is should not appear in the abstraction

presented to the user.

[Page 5]

bbs.theithome.com

The program that hides the truth about the hardware from the programmer and presents a nice,

simple view of named files that can be read and written is, of course, the operating system. Just as

the operating system shields the programmer from the disk hardware and presents a simple file-

oriented interface, it also conceals a lot of unpleasant business concerning interrupts, timers,

memory management, and other low-level features. In each case, the abstraction offered by the

operating system is simpler and easier to use than that offered by the underlying hardware.

In this view, the function of the operating system is to present the user with the equivalent of an

extended machine or virtual machine that is easier to program than the underlying hardware.

How the operating system achieves this goal is a long story, which we will study in detail

throughout this book. To summarize it in a nutshell, the operating system provides a variety of

services that programs can obtain using special instructions called system calls. We will examine

some of the more common system calls later in this chapter.

1.1.2. The Operating System as a Resource Manager

The concept of the operating system as primarily providing its users with a convenient interface is a

top-down view. An alternative, bottom-up, view holds that the operating system is there to manage

all the pieces of a complex system. Modern computers consist of processors, memories, timers,

disks, mice, network interfaces, printers, and a wide variety of other devices. In the alternative

view, the job of the operating system is to provide for an orderly and controlled allocation of the

processors, memories, and I/O devices among the various programs competing for them.

Imagine what would happen if three programs running on some computer all tried to print their

output simultaneously on the same printer. The first few lines of printout might be from program 1,

the next few from program 2, then some from program 3, and so forth. The result would be chaos.

The operating system can bring order to the potential chaos by buffering all the output destined for

the printer on the disk. When one program is finished, the operating system can then copy its

output from the disk file where it has been stored to the printer, while at the same time the other

program can continue generating more output, oblivious to the fact that the output is not really

going to the printer (yet).

When a computer (or network) has multiple users, the need for managing and protecting the

memory, I/O devices, and other resources is even greater, since the users might otherwise

interfere with one another. In addition, users often need to share not only hardware, but

information (files, databases, etc.) as well. In short, this view of the operating system holds that its

primary task is to keep track of who is using which resource, to grant resource requests, to account

for usage, and to mediate conflicting requests from different programs and users.

[Page 6]

Resource management includes multiplexing (sharing) resources in two ways: in time and in space.

When a resource is time multiplexed, different programs or users take turns using it. First one of

them gets to use the resource, then another, and so on. For example, with only one CPU and

multiple programs that want to run on it, the operating system first allocates the CPU to one

program, then after it has run long enough, another one gets to use the CPU, then another, and

then eventually the first one again. Determining how the resource is time multiplexedwho goes

next and for how longis the task of the operating system. Another example of time multiplexing is

sharing the printer. When multiple print jobs are queued up for printing on a single printer, a

decision has to be made about which one is to be printed next.

bbs.theithome.com

[Page 6 (continued)]

1.2. History of Operating Systems

Operating systems have been evolving through the years. In the following sections we will briefly

look at a few of the highlights. Since operating systems have historically been closely tied to the

architecture of the computers on which they run, we will look at successive generations of

computers to see what their operating systems were like. This mapping of operating system

generations to computer generations is crude, but it does provide some structure where there

would otherwise be none.

The first true digital computer was designed by the English mathematician Charles Babbage

(17921871). Although Babbage spent most of his life and fortune trying to build his "analytical

engine," he never got it working properly because it was purely mechanical, and the technology of

his day could not produce the required wheels, gears, and cogs to the high precision that he

needed. Needless to say, the analytical engine did not have an operating system.

As an interesting historical aside, Babbage realized that he would need software for his analytical

engine, so he hired a young woman named Ada Lovelace, who was the daughter of the famed

British poet Lord Byron, as the world's first programmer. The programming language Ada

was

named after her.

[Page 7]

1.2.1. The First Generation (194555) Vacuum Tubes and Plugboards

After Babbage's unsuccessful efforts, little progress was made in constructing digital computers

until World War II. Around the mid-1940s, Howard Aiken at Harvard University, John von Neumann

at the Institute for Advanced Study in Princeton, J. Presper Eckert and John Mauchley at the

University of Pennsylvania, and Konrad Zuse in Germany, among others, all succeeded in building

calculating engines. The first ones used mechanical relays but were very slow, with cycle times

measured in seconds. Relays were later replaced by vacuum tubes. These machines were

enormous, filling up entire rooms with tens of thousands of vacuum tubes, but they were still

millions of times slower than even the cheapest personal computers available today.

In these early days, a single group of people designed, built, programmed, operated, and

maintained each machine. All programming was done in absolute machine language, often by

wiring up plugboards to control the machine's basic functions. Programming languages were

unknown (even assembly language was unknown). Operating systems were unheard of. The usual

mode of operation was for the programmer to sign up for a block of time on the signup sheet on

the wall, then come down to the machine room, insert his or her plugboard into the computer, and

spend the next few hours hoping that none of the 20,000 or so vacuum tubes would burn out

during the run. Virtually all the problems were straightforward numerical calculations, such as

grinding out tables of sines, cosines, and logarithms.

By the early 1950s, the routine had improved somewhat with the introduction of punched cards. It

bbs.theithome.com

was now possible to write programs on cards and read them in instead of using plugboards;

otherwise, the procedure was the same.

1.2.2. The Second Generation (195565) Transistors and Batch Systems

The introduction of the transistor in the mid-1950s changed the picture radically. Computers

became reliable enough that they could be manufactured and sold to paying customers with the

expectation that they would continue to function long enough to get some useful work done. For

the first time, there was a clear separation between designers, builders, operators, programmers,

and maintenance personnel.

These machines, now called mainframes, were locked away in specially airconditioned computer

rooms, with staffs of specially-trained professional operators to run them. Only big corporations or

major government agencies or universities could afford their multimillion dollar price tags. To run a

job (i.e., a program or set of programs), a programmer would first write the program on paper (in

FORTRAN or possibly even in assembly language), then punch it on cards. He would then bring the

card deck down to the input room and hand it to one of the operators and go drink coffee until the

output was ready.

[Page 8]

When the computer finished whatever job it was currently running, an operator would go over to

the printer and tear off the output and carry it over to the output-room, so that the programmer

could collect it later. Then he would take one of the card decks that had been brought from the

input room and read it in. If the FORTRAN compiler was needed, the operator would have to get it

from a file cabinet and read it in. Much computer time was wasted while operators were walking

around the machine room.

Given the high cost of the equipment, it is not surprising that people quickly looked for ways to

reduce the wasted time. The solution generally adopted was the batch system. The idea behind it

was to collect a tray full of jobs in the input room and then read them onto a magnetic tape using a

small (relatively) inexpensive computer, such as the IBM 1401, which was very good at reading

cards, copying tapes, and printing output, but not at all good at numerical calculations. Other,

much more expensive machines, such as the IBM 7094, were used for the real computing. This

situation is shown in Fig. 1-2.

Figure 1-2. An early batch system. (a) Programmers bring cards to 1401.

(b) 1401 reads batch of jobs onto tape. (c) Operator carries input tape to

7094. (d) 7094 does computing. (e) Operator carries output tape to

1401. (f) 1401 prints output.

[View full size image]

bbs.theithome.com

剩余1173页未读，继续阅读

dong8chao3

粉丝: 0
资源: 6

《操作系统设计与实现》第3版英文PDF资源

操作系统设计与实现 第3版 上.pdf

操作系统设计与实现 英文版 第三版

FreeBSD操作系统设计与实现2nd 完整书签英文版

操作系统 精髓与设计原理 第3版.pdf

《操作系统设计与实现(第3版)》PDF完整版：MINIX3详解与教学经典

Linux内核设计与实现+原书第3版.pdf

绝对正版-计算机操作系统西安科大(第3版)课后习题答案.pdf

控制系统设计指南（第3版）

计算机操作系统实验指导（第3版）

《计算机系统程序员视角》第3版高清PDF无痕解读

最新资源

操作系统设计与实现第3版上.pdf

操作系统设计与实现英文版第三版

操作系统精髓与设计原理第3版.pdf