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

5星 · 超过95%的资源需积分: 9 14 浏览量更新于2024-07-24 3 收藏 33.91MB PDF 举报

"操作系统设计与实现第3版是Andrew S. Tanenbaum和Albert S. Woodhull合作编写的一本专业教材，适用于深入理解操作系统的内核结构和设计。本书由Prentice Hall出版社于2006年1月出版，旨在介绍最新的MINIX 3系统，特别强调高可靠性、嵌入式系统应用以及教学的便利性。读者可以通过访问www.minix3.org获取MINIX的最新版本和模拟器，以便在其他系统上运行MINIX。" 操作系统设计是计算机科学中的核心领域，这本书第三版针对这一主题提供了深入的理论知识和实践案例。作者通过讲解相关原理，然后以类Unix操作系统MINIX为例，展示了这些原理的实际应用。MINIX 3是一个开源的操作系统项目，其设计目标是提高系统的稳定性和可靠性，这使得它在嵌入式系统和需要高度可靠性的环境中尤为适用。在本书中，读者可以期待学习到以下关键知识点： 1. **操作系统基础**：涵盖操作系统的基本概念，如进程管理、内存管理、文件系统和I/O管理，这些都是操作系统的核心组成部分。 2. **进程管理**：包括进程创建、撤销、调度、同步和通信等，这些是多任务环境下操作系统协调不同进程的关键机制。 3. **内存管理**：涉及虚拟内存、页面替换算法、内存分配策略等，这些内容对于优化系统性能和资源利用率至关重要。 4. **文件系统**：介绍文件的组织、存储、访问和保护，以及日志文件系统和分布式文件系统等高级主题。 5. **输入/输出(I/O)管理**：涵盖设备驱动程序、中断处理、DMA（直接内存访问）和I/O调度，这些是操作系统与硬件交互的基础。 6. **系统安全与保护**：讨论访问控制、权限模型和防止恶意攻击的方法，确保系统的安全性。 7. **实时与嵌入式系统**：阐述这些特定领域的操作系统设计挑战，如响应时间、确定性和资源受限环境下的优化。 8. **MINIX 3系统**：详细解析MINIX 3的设计和实现，让读者能够理解和模仿一个实际操作系统的工作方式。 9. **教学与实验**：书中包含的教学方法和MINIX 3模拟器，为学生提供了动手实践的机会，加深对理论知识的理解。通过阅读和研究这本书，读者不仅可以掌握操作系统设计的基本原理，还能了解到当前操作系统领域的发展趋势和技术挑战。无论是对于计算机科学的学生还是操作系统开发者，这都是一本不可或缺的参考资料。

[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页未读，继续阅读

卧浪居士

粉丝: 53

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

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

操作系统&设计与实现(英文)

操作系统设计与实现（中英文各一）

面向对象分析与设计（第3版）.pdf

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

Hadoop 权威指南（英文第3版）.pdf

C++入门经典(第3版).pdf

UNIX环境高级编程(第3版).pdf

MySQL 5权威指南（第3版）.pdf

FMEA潜在失效模式（第3版）.pdf

最新资源

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

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