Tanenbaum与Woodhull的《操作系统设计与实现》第三版概览

需积分: 25 17 浏览量更新于2024-07-25 收藏 8.47MB PDF 举报

"Operating Systems Design & Implementation 3rd Edition 是一本由Andrew S. Tanenbaum和Albert S. Woodhull合著的操作系统设计与实现的教材，主要关注最新的MINIX 3版本。这本书由Prentice Hall出版社在2006年1月出版，包含了1080页的内容，旨在通过一个类似Unix的操作系统实例来讲解操作系统的设计原则和应用，特别适合于高可靠性、嵌入式系统以及教学使用。最新版MINIX 3和模拟器可以在www.minix3.org获取。" 《操作系统设计与实现》第三版是操作系统领域的经典教材，作者是荷兰Vrije Universiteit Amsterdam的Andrew S. Tanenbaum和美国Amherst的Albert S. Woodhull。这本书的特色在于它不仅深入讲解了操作系统设计的基础理论，而且还结合了一个具体实例——MINIX 3，这是一个简化版的开源操作系统，具有高度的可靠性和适应性，常被用于教学和嵌入式系统的开发。书中涵盖了操作系统设计的多个关键知识点，包括但不限于： 1. **进程管理**：讨论进程的创建、销毁、同步和通信机制，以及调度策略如FCFS（先来先服务）、SJF（最短作业优先）和多级反馈队列等。 2. **内存管理**：介绍虚拟内存的概念，如何进行页面替换算法（如LRU、LFU），以及内存分配和回收策略。 3. **文件系统**：阐述文件的组织结构，I/O操作，目录管理，以及文件系统的安全性和恢复机制。 4. **设备管理**：讲解设备驱动程序的工作原理，I/O控制方式（中断、DMA等），以及缓冲区管理和设备共享策略。 5. **网络与通信**：涉及网络协议栈的实现，套接字编程，以及进程间通信（IPC）机制如管道、消息队列、共享内存和信号量。 6. **安全性与可靠性**：探讨操作系统如何确保数据安全，防止恶意攻击，并实现高可用性和故障恢复。 7. **MINIX 3系统**：书中以MINIX 3为例，展示了这些概念如何在实际操作系统中应用，帮助读者理解理论与实践之间的关系。 8. **模拟器与实验**：提供MINIX 3的模拟器，使学生能在不同平台上运行和实验，加深对操作系统的实际操作理解。通过本书的学习，读者不仅可以掌握操作系统设计的基本原理，还能获得实践操作的经验，这对软件工程师、系统管理员以及计算机科学专业的学生来说都是一份宝贵的资源。同时，MINIX 3项目的持续更新和发展也使得该书的内容始终保持前沿性。

[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 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]

By the early 1960s, most computer manufacturers had two distinct, and totally incompatible,

product lines. On the one hand there were the word-oriented, large-scale scientific computers,

such as the 7094, which were used for numerical calculations in science and engineering. On the

other hand, there were the character-oriented, commercial computers, such as the 1401, which

were widely used for tape sorting and printing by banks and insurance companies.

Developing, maintaining, and marketing two completely different product lines was an expensive

proposition for the computer manufacturers. In addition, many new computer customers initially

needed a small machine but later outgrew it and wanted a bigger machine that had the same

architectures as their current one so it could run all their old programs, but faster.

[Page 10]

IBM attempted to solve both of these problems at a single stroke by introducing the System/360.

The 360 was a series of software-compatible machines ranging from 1401-sized to much more

powerful than the 7094. The machines differed only in price and performance (maximum

memory, processor speed, number of I/O devices permitted, and so forth). Since all the machines

had the same architecture and instruction set, programs written for one machine could run on all

the others, at least in theory. Furthermore, the 360 was designed to handle both scientific (i.e.,

numerical) and commercial computing. Thus a single family of machines could satisfy the needs of

all customers. In subsequent years, IBM has come out with compatible successors to the 360 line,

using more modern technology, known as the 370, 4300, 3080, 3090, and Z series.

The 360 was the first major computer line to use (small-scale) Integrated Circuits (ICs), thus

providing a major price/performance advantage over the second-generation machines, which

were built up from individual transistors. It was an immediate success, and the idea of a family of

compatible computers was soon adopted by all the other major manufacturers. The descendants

of these machines are still in use at computer centers today. Nowadays they are often used for

managing huge databases (e.g., for airline reservation systems) or as servers for World Wide

Web sites that must process thousands of requests per second.

The greatest strength of the "one family" idea was simultaneously its greatest weakness. The

intention was that all software, including the operating system, OS/360, had to work on all

models. It had to run on small systems, which often just replaced 1401s for copying cards to

tape, and on very large systems, which often replaced 7094s for doing weather forecasting and

other heavy computing. It had to be good on systems with few peripherals and on systems with

many peripherals. It had to work in commercial environments and in scientific environments.

Above all, it had to be efficient for all of these different uses.

There was no way that IBM (or anybody else) could write a piece of software to meet all those

conflicting requirements. The result was an enormous and extraordinarily complex operating

system, probably two to three orders of magnitude larger than FMS. It consisted of millions of

lines of assembly language written by thousands of programmers, and contained thousands upon

thousands of bugs, which necessitated a continuous stream of new releases in an attempt to

correct them. Each new release fixed some bugs and introduced new ones, so the number of bugs

probably remained constant in time.

One of the designers of OS/360, Fred Brooks, subsequently wrote a witty and incisive book

describing his experiences with OS/360 (Brooks, 1995). While it would be impossible to

summarize the book here, suffice it to say that the cover shows a herd of prehistoric beasts stuck

in a tar pit. The cover of Silberschatz et al. (2004) makes a similar point about operating systems

being dinosaurs.

[Page 11]

Despite its enormous size and problems, OS/360 and the similar third-generation operating

systems produced by other computer manufacturers actually satisfied most of their customers

reasonably well. They also popularized several key techniques absent in second-generation

operating systems. Probably the most important of these was multiprogramming. On the 7094,

when the current job paused to wait for a tape or other I/O operation to complete, the CPU

simply sat idle until the I/O finished. With heavily CPU-bound scientific calculations, I/O is

infrequent, so this wasted time is not significant. With commercial data processing, the I/O wait

time can often be 80 or 90 percent of the total time, so something had to be done to avoid having

the (expensive) CPU be idle so much.

The solution that evolved was to partition memory into several pieces, with a different job in each

partition, as shown in Fig. 1-4. While one job was waiting for I/O to complete, another job could

be using the CPU. If enough jobs could be held in main memory at once, the CPU could be kept

busy nearly 100 percent of the time. Having multiple jobs safely in memory at once requires

special hardware to protect each job against snooping and mischief by the other ones, but the

360 and other third-generation systems were equipped with this hardware.

Figure 1-4. A multiprogramming system with three jobs in memory.

Another major feature present in third-generation operating systems was the ability to read jobs

from cards onto the disk as soon as they were brought to the computer room. Then, whenever a

running job finished, the operating system could load a new job from the disk into the now-empty

partition and run it. This technique is called spooling (from Simultaneous Peripheral Operation

On Line) and was also used for output. With spooling, the 1401s were no longer needed, and

much carrying of tapes disappeared.

Although third-generation operating systems were well suited for big scientific calculations and

massive commercial data processing runs, they were still basically batch systems. Many

programmers pined for the first-generation days when they had the machine all to themselves for

a few hours, so they could debug their programs quickly. With third-generation systems, the time

between submitting a job and getting back the output was often hours, so a single misplaced

comma could cause a compilation to fail, and the programmer to waste half a day.

This desire for quick response time paved the way for timesharing, a variant of

multiprogramming, in which each user has an online terminal. In a timesharing system, if 20

users are logged in and 17 of them are thinking or talking or drinking coffee, the CPU can be

allocated in turn to the three jobs that want service. Since people debugging programs usually

issue short commands (e.g., compile a five-page procedure

[ ]

) rather than long ones (e.g., sort a

million-record file), the computer can provide fast, interactive service to a number of users and

perhaps also work on big batch jobs in the background when the CPU is otherwise idle. The first

serious timesharing system, CTSS (Compatible Time Sharing System), was developed at M.I.T.

on a specially modified 7094 (Corbató et al., 1962). However, timesharing did not really become

剩余1098页未读，继续阅读

jyw893286315

粉丝: 0
资源: 2

Tanenbaum与Woodhull的《操作系统设计与实现》第三版概览

深入解析Operating Systems Design and Implementation 2nd

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

Tanenbaum的《操作系统设计与实现》第三版：MINIX3详解

Operating Systems Design & Implementation 3rd Edition

Operating Systems Design and Implementation 3rd Edition

Operating Systems Design and Implementation, 3rd Edition chm

Operating Systems Design and Implementation(3rd Edition)

Operating Systems Design and Implementation(3rd Edition).rar

the_minix_book_operating-systems-design-implementation-3rd-edition(书 及 其课后习题答案)

operating system design and implementation

最新资源

the_minix_book_operating-systems-design-implementation-3rd-edition(书及其课后习题答案)