操作系统设计原理6版答案详解，附书签

操作系统

需积分: 0 26 浏览量更新于2024-06-14 收藏 2.68MB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

"操作系统：精髓与设计原理(第6版)英文答案及书签" 操作系统是计算机科学中的核心课程，本书《操作系统：精髓与设计原理》由威廉·斯托林斯（William Stallings）撰写，提供了深入理解操作系统内部机制和设计策略的详细内容。这本书的第六版解决方案手册包含了对书中各个章节的复习问题和作业题目的解答，帮助读者巩固学习并深化对操作系统的理解。第一章“计算机系统概览”涵盖了计算机硬件的基本组件，如CPU、内存和I/O设备，以及它们如何协同工作来执行程序。这一章也讨论了计算机体系结构的不同类型，包括CISC（复杂指令集计算）和RISC（精简指令集计算）。第二章“操作系统概述”介绍了操作系统的功能和角色，包括进程管理、内存管理、文件系统、输入/输出管理以及安全性。此外，还讨论了操作系统的不同类型，如批处理、分时、实时和网络操作系统。第三章“进程描述与控制”详细阐述了进程的概念，包括进程状态转换、调度算法、同步与通信机制，以及死锁的基本概念。第四章“线程、SMP和微内核”引入了多线程的概念，解释了它们如何提高处理器的效率，并讨论了对称多处理器（SMP）系统的设计和性能。微内核架构在此章中也有提及，它强调了将操作系统服务移到用户空间的优越性。第五章“并发：互斥与同步”深入探讨了在并发环境下如何通过互斥量、信号量、条件变量等工具来实现资源的共享和同步，防止数据竞争和不一致性。第六章“并发：死锁与饥饿”聚焦于并发系统中的两个主要问题：死锁（多个进程相互等待对方释放资源导致的僵局）和饥饿（一个或多个进程无法获得必要的资源而无限期等待）。本章提供了识别和避免这些问题的策略和算法。这本书的解决方案手册是学习操作系统理论和实践的宝贵资源，作者鼓励读者在发现错误或问题时通过电子邮件（ws@shore.net）向他报告，以便更新和改进。如果有任何更正或更新，可以在提供的链接（http://www.box.net/public/ig0eifhfxu）上找到错误表（如果需要的话）。这是一本全面覆盖操作系统核心概念和技术的教材，适合计算机科学专业的学生以及对操作系统感兴趣的从业者。通过阅读和解决书中提供的问题，读者可以深入掌握操作系统设计的核心原理和实现细节。

资源详情

资源推荐

-16-

constraints related to the amount of memory devoted to the process state for

each process. At most N processes can be in the Running state, one for each

processor.

b. Zero is the minimum number of processes in each state. It is possible for all

processes to be in either the Running state (up to N processes) or the Ready

state, with no process blocked. It is possible for all processes to be blocked

waiting for I/O operations, with zero processes in the Ready and Running

states.

3.3 a. New → Ready or Ready/Suspend: covered in text

Ready → Running or Ready/Suspend: covered in text

Ready/Suspend → Ready: covered in text

Blocked → Ready or Blocked/Suspend: covered in text

Blocked/Suspend → Ready /Suspend or Blocked: covered in text

Running → Ready, Ready/Suspend, or Blocked: covered in text

Any State → Exit: covered in text

b. New → Blocked, Blocked/Suspend, or Running: A newly created process

remains in the new state until the processor is ready to take on an additional

process, at which time it goes to one of the Ready states.

Ready → Blocked or Blocked/Suspend: Typically, a process that is ready

cannot subsequently be blocked until it has run. Some systems may allow the

OS to block a process that is currently ready, perhaps to free up resources

committed to the ready process.

Ready/Suspend → Blocked or Blocked/Suspend: Same reasoning as

preceding entry.

Ready/Suspend → Running: The OS first brings the process into memory,

which puts it into the Ready state.

Blocked → Ready /Suspend: this transition would be done in 2 stages. A

blocked process cannot at the same time be made ready and suspended,

because these transitions are triggered by two different causes.

Blocked → Running: When a process is unblocked, it is put into the Ready

state. The dispatcher will only choose a process from the Ready state to run

Blocked/Suspend → Ready: same reasoning as Blocked → Ready /Suspend

Blocked/Suspend → Running: same reasoning as Blocked → Running

Running → Blocked/Suspend: this transition would be done in 2 stages

Exit → Any State: Can't turn back the clock

3.4 The following example is used in [PINK89] to clarify their definition of block and

suspend:

Suppose a process has been executing for a while and needs an additional

magnetic tape drive so that it can write out a temporary file. Before it can

initiate a write to tape, it must be given permission to use one of the drives.

When it makes its request, a tape drive may not be available, and if that is the

case, the process will be placed in the blocked state. At some point, we assume

the system will allocate the tape drive to the process; at that time the process

will be moved back to the active state. When the process is placed into the

execute state again it will request a write operation to its newly acquired tape

drive. At this point, the process will be move to the suspend state, where it

waits for the completion of the current write on the tape drive that it now

owns.

-17-

The distinction made between two different reasons for waiting for a device could

be useful to the operating system in organizing its work. However, it is no

substitute for a knowledge of which processes are swapped out and which

processes are swapped in. This latter distinction is a necessity and must be reflected

in some fashion in the process state.

3.5 Figure 9.3 in Chapter 9 shows the result for a single blocked queue. The figure

readily generalizes to multiple blocked queues.

3.6 Penalize the Ready, suspend processes by some fixed amount, such as one or two

priority levels, so that a Ready, suspend process is chosen next only if it has a

higher priority than the highest-priority Ready process by several levels of priority.

3.7 a. A separate queue is associated with each wait state. The differentiation of

waiting processes into queues reduces the work needed to locate a waiting

process when an event occurs that affects it. For example, when a page fault

completes, the scheduler know that the waiting process can be found on the

Page Fault Wait queue.

b. In each case, it would be less efficient to allow the process to be swapped out

while in this state. For example, on a page fault wait, it makes no sense to swap

out a process when we are waiting to bring in another page so that it can

execute.

c. The state transition diagram can be derived from the following state transition

table:

Next State

Current State

Currently

Executing

Computable

(resident)

Computable

(outswapped)

Variety of wait

states (resident)

Variety of wait

states

(outswapped)

Currently

Executing

Rescheduled

Wait

Computable

(resident)

Scheduled

Outswap

Computable

(outswapped)

Inswap

Variety of wait

states (resident)

Event satisfied

Outswap

Variety of wait

states

(outswapped)

Event satisfied

3.8 a. The advantage of four modes is that there is more flexibility to control access to

memory, allowing finer tuning of memory protection. The disadvantage is

complexity and processing overhead. For example, procedures running at each

of the access modes require separate stacks with appropriate accessibility.

b. In principle, the more modes, the more flexibility, but it seems difficult to

justify going beyond four.

-18-

3.9 a. With j < i, a process running in D

is prevented from accessing objects in D

Thus, if D

contains information that is more privileged or is to be kept more

secure than information in D

, this restriction is appropriate. However, this

security policy can be circumvented in the following way. A process running in

could read data in D

and then copy that data into D

. Subsequently, a

process running in D

could access the information.

b. An approach to dealing with this problem, known as a trusted system, is

discussed in Chapter 16.

3.10 a. An application may be processing data received from another process and

storing the results on disk. If there is data waiting to be taken from the other

process, the application may proceed to get that data and process it. If a

previous disk write has completed and there is processed data to write out, the

application may proceed to write to disk. There may be a point where the

process is waiting both for additional data from the input process and for disk

availability.

b. There are several ways that could be handled. A special type of either/or

queue could be used. Or the process could be put in two separate queues. In

either case, the operating system would have to handle the details of alerting

the process to the occurrence of both events, one after the other.

3.11 This technique is based on the assumption that an interrupted process A will

continue to run after the response to an interrupt. But, in general, an interrupt may

cause the basic monitor to preempt a process A in favor of another process B. It is

now necessary to copy the execution state of process A from the location associated

with the interrupt to the process description associated with A. The machine might

as well have stored them there in the first place. Source: [BRIN73].

3.12 Because there are circumstances under which a process may not be preempted

(i.e., it is executing in kernel mode), it is impossible for the operating system to

respond rapidly to real-time requirements.

-19-

CHAPTER 4 THREADS, SMP AND

MICROKERNELS

NSWERS TO

UESTIONS

4.1 This will differ from system to system, but in general, resources are owned by the

process and each thread has its own execution state. A few general comments about

each category in Table 3.5: Identification: the process must be identified but each

thread within the process must have its own ID. Processor State Information: these

are generally process-related. Process control information: scheduling and state

information would mostly be at the thread level; data structuring could appear at

both levels; interprocess communication and interthread communication may both

be supported; privileges may be at both levels; memory management would

generally be at the process level; and resource info would generally be at the

process level.

4.2 Less state information is involved.

4.3 Resource ownership and scheduling/execution.

4.4 Foreground/background work; asynchronous processing; speedup of execution by

parallel processing of data; modular program structure.

4.5 Address space, file resources, execution privileges are examples.

4.6 1. Thread switching does not require kernel mode privileges because all of the

thread management data structures are within the user address space of a single

process. Therefore, the process does not switch to the kernel mode to do thread

management. This saves the overhead of two mode switches (user to kernel; kernel

back to user). 2. Scheduling can be application specific. One application may benefit

most from a simple round-robin scheduling algorithm, while another might benefit

from a priority-based scheduling algorithm. The scheduling algorithm can be

tailored to the application without disturbing the underlying OS scheduler. 3. ULTs

can run on any operating system. No changes are required to the underlying kernel

to support ULTs. The threads library is a set of application-level utilities shared by

all applications.

4.7 1. In a typical operating system, many system calls are blocking. Thus, when a ULT

executes a system call, not only is that thread blocked, but also all of the threads

within the process are blocked. 2. In a pure ULT strategy, a multithreaded

application cannot take advantage of multiprocessing. A kernel assigns one process

-20-

to only one processor at a time. Therefore, only a single thread within a process can

execute at a time.

4.8 Jacketing converts a blocking system call into a nonblocking system call by using an

application-level I/O routine which checks the status of the I/O device.

4.9 SIMD: A single machine instruction controls the simultaneous execution of a

number of processing elements on a lockstep basis. Each processing element has an

associated data memory, so that each instruction is executed on a different set of

data by the different processors.. MIMD: A set of processors simultaneously

execute different instruction sequences on different data sets. Master/slave: The

operating system kernel always runs on a particular processor. The other

processors may only execute user programs and perhaps operating system utilities.

SMP: the kernel can execute on any processor, and typically each processor does

self-scheduling from the pool of available processes or threads. Cluster: Each

processor has a dedicated memory, and is a self-contained computer.

4.10 Simultaneous concurrent processes or threads; scheduling; synchronization;

memory management; reliability and fault tolerance.

4.11 Device drivers, file systems, virtual memory manager, windowing system, and

security services.

4.12 Uniform interfaces: Processes need not distinguish between kernel-level and user-

level services because all such services are provided by means of message passing.

Extensibility: facilitates the addition of new services as well as the provision of

multiple services in the same functional area. Flexibility: not only can new

features be added to the operating system, but existing features can be subtracted

to produce a smaller, more efficient implementation. Portability: all or at least

much of the processor-specific code is in the microkernel; thus, changes needed to

port the system to a new processor are fewer and tend to be arranged in logical

groupings. Reliability: A small microkernel can be rigorously tested. Its use of a

small number of application programming interfaces (APIs) improves the chance

of producing quality code for the operating-system services outside the kernel.

Distributed system support: the message orientation of microkernal

communication lends itself to extension to distributed systems. Support for

object-oriented operating system (OOOS): An object-oriented approach can lend

discipline to the design of the microkernel and to the development of modular

extensions to the operating system.

4.13 It takes longer to build and send a message via the microkernel, and accept and

decode the reply, than to make a single service call.

4.14 These functions fall into the general categories of low-level memory management,

inter-process communication (IPC), and I/O and interrupt management.

4.15 Messages.

NSWERS TO

ROBLEMS

剩余111页未读，继续阅读

DragonWarrior8

粉丝: 0
资源: 1

操作系统设计原理6版答案详解，附书签

操作系统：精髓与设计原理第六版英文答案

操作系统：精髓与设计原理(英文第六版)

操作系统：精髓与设计原理(第6版）英文版答案

操作系统：精髓与设计原理 第6版 Operating Systems Internals and Design Principles 6th 高清彩色

Operating Systems Internals and Design Principles 6th

Stallings - Operating Systems_ Internals and Design Principles 8th Edition c2015

Operating Systems Internals and Design Principles, 9th Edition

Operating Systems Internals and Design Principles (5th Edition)

Operating Systems Internals and Design Principles (6th Edition) -part2

Operating Systems Internals and Design Principles (6th Edition)-part1

Operating Systems Internals and Design Principles (9th).rar

Prentice Operating Systems Internals and Design Principles (6th edtion 2008by Stallings).pdf

Operating Systems Internals and Design Principles (6,7,8,9th Edition)

Operating Systems Internals and Design Principles, 9E ,Test Bank

Operating_Systems_Internals_and_Design_Principles_9th_Edition

Operating.Systems.Internals.and.Design.Principles1

[英文原版]操作系统_精髓与设计原理_第6版 - Chapter6-new

最新资源

操作系统：精髓与设计原理第6版 Operating Systems Internals and Design Principles 6th 高清彩色