收藏 分享(赏)

操作系统-精髓与设计原理_WILLIAM_STALLINGS_课后答案.pdf

上传人:HR专家 文档编号:6263840 上传时间:2019-04-03 格式:PDF 页数:35 大小:468.61KB
下载 相关 举报
操作系统-精髓与设计原理_WILLIAM_STALLINGS_课后答案.pdf_第1页
第1页 / 共35页
操作系统-精髓与设计原理_WILLIAM_STALLINGS_课后答案.pdf_第2页
第2页 / 共35页
操作系统-精髓与设计原理_WILLIAM_STALLINGS_课后答案.pdf_第3页
第3页 / 共35页
操作系统-精髓与设计原理_WILLIAM_STALLINGS_课后答案.pdf_第4页
第4页 / 共35页
操作系统-精髓与设计原理_WILLIAM_STALLINGS_课后答案.pdf_第5页
第5页 / 共35页
点击查看更多>>
资源描述

1、 课 后答案 网 ,用心 为 你 服 务 ! 大学答案 - 中学答案 - 考研答案 - 考试答案 最全最多的课后习题参考答案,尽在课后答案网()! Khdaw团队一直秉承用心为大家服务的宗旨,以关注学生的学习生活为出发点, 旨在为广大学生朋友的自主学习提供一个分享和交流的平台。 爱校园() 课后答案网() 淘答案() SOLUTIONS TO PRACTICE PROBLEMS OPERATING SYSTEMS: INTERNALS AND DESIGN PRINCIPLES FIFTH EDITION WILLIAM STALLINGS Copyright 2007: William St

2、allings -2- -3- Chapter 1 Computer System Overview.4 Chapter 2 Operating System Overview.7 Chapter 3 Process Description and Control8 Chapter 5 Concurrency: Mutual Exclusion and Synchronization .10 Chapter 6 Concurrency: Deadlock and Starvation 17 Chapter 7 Memory Management .20 Chapter 8 Virtual Me

3、mory 22 Chapter 9 Uniprocessor Scheduling.28 Chapter 11 I/O Management and Disk Scheduling32 Chapter 12 File Management 34 TABLE OF CONTENTS -4- CHAPTER 1 COMPUTER SYSTEM OVERVIEW 1.1 In hardware: device sends signal (voltage) on IRQ line. The signal causes a bit to be flipped in the interrupt regis

4、ter. At the end of an instruction cycle, the interrupt register is checked (in priority order) and, if a bit is on, the hardware places the value currently in the PC (typically) on the system stack and goes to the interrupt vector, at the location matched to the interrupt register, to get the addres

5、s of the ISR. This address is placed in the PC register. In software: the ISR begins to execute. It will save values in registers that it will need, perhaps on the stack, perhaps in the previous processs PCB. It may disable interrupts long enough to save these values. It may have to identify one of

6、several devices using that IRQ line (if devices share a signal). It will handle the interrupt. It may restore the interrupted processs register values (note that sometimes processes are terminated, etc.). 1.2 a. Addresses Contents 0x0000B128 0x0200EC00 0x0000B12C 0x0300EC04 0x0000B130 0x0100EC08 (1s

7、t byte: opcode (e.g., 0x02), remaining 3 bytes are address of data) 0x0000EC00 0x00000016 ; (a=22=0x16) 0x0000EC04 0x0000009E ; (b=158=0x9E) 0x0000EC08 0x00000000 ; (c=0=0x00, or it can be anything) b. Instruction Contents PC MAR 0x0000B128 M MBR 0x0200EC00 MBR IR 0x0200EC00 IR MAR 0x0000EC00 M MBR

8、0x00000016 MBR AC 0x00000016 PC MAR 0x0000B12C M MBR 0x0300EC04 MBR IR 0x0300EC04 IR MAR 0x0000EC04 M MBR 0x0000009E MBR + AC AC 0x00000B4 PC MAR 0x0000B130 M MBR 0x0100EC08 MBR IR 0x0100EC08 IR MAR 0x0000EC08 AC MBR 0x000000B4 MBR M 0x000000B4 -5- -6- 1.3 EAT = .9 (10) + .1 .8 (10 + 100) + .2 (10 +

9、 100 + 10000) = 220ns OR EAT = 10 + .1 (100) + .02 (10000) = 220ns 1.4 a. Since the targeted memory module (MM) becomes available for another transaction 600 ns after the initiation of each store operation, and there are 8 MMs, it is possible to initiate a store operation every 100 ns. Thus, the max

10、imum number of stores that can be initiated in one second would be: 10 9 /10 2= 10 7words per second Strictly speaking, the last five stores that are initiated are not completed until sometime after the end of that second, so the maximum transfer rate is really 10 7 5 words per second. b. From the a

11、rgument in part (a), it is clear that the maximum write rate will be essentially 10 7words per second as long as a MM is free in time to avoid delaying the initiation of the next write. For clarity, let the module cycle time include the bus busy time as well as the internal processing time the MM ne

12、eds. Thus in part (a), the module cycle time was 600 ns. Now, so long as the module cycle time is 800 ns or less, we can still achieve 10 7words per second; after that, the maximum write rate will slowly drop off toward zero. -7- CHAPTER 2 OPERATING SYSTEM OVERVIEW 2.1 a. I/O-bound processes use lit

13、tle processor time; thus, the algorithm will favor I/O-bound processes. b. if CPU-bound process is denied access to the processor = the CPU-bound process wont use the processor in the recent past. = the CPU-bound process wont be permanently denied access. 2.2 a. The time required to execute a batch

14、is M + (N T), and the cost of using the processor for this amount of time and letting N users wait meanwhile is (M + (N T) (S + (N W). The total cost of service time and waiting time per customer is C = (M + (N T) (S + (N W)/N The result follows by setting dC/dN = 0 b. $0.60/hour. 2.3 The countermea

15、sure taken was to cancel any job request that had been waiting for more than one hour without being honored. 2.4 The problem was solved by postponing the execution of a job until all its tapes were mounted. 2.5 An effective solution is to keep a single copy of the most frequently used procedures for

16、 file manipulation, program input and editing permanently (or semi-permanently) in the internal store and thus enable user programs to call them directly. Otherwise, the system will spend a considerable amount of time multiple copies of utility programs for different users. -8- CHAPTER 3 PROCESS DES

17、CRIPTION AND CONTROL 3.1 RUN to READY can be caused by a time-quantum expiration READY to NONRESIDENT occurs if memory is overcommitted, and a process is temporarily swapped out of memory READY to RUN occurs only if a process is allocated the CPU by the dispatcher RUN to BLOCKED can occur if a proce

18、ss issues an I/O or other kernel request. BLOCKED to READY occurs if the awaited event completes (perhaps I/O completion) BLOCKED to NONRESIDENT - same as READY to NONRESIDENT. 3.2 0 or 0 3.3 At time 22: P1: blocked for I/O P3: blocked for I/O P5: ready/running P7: blocked for I/O P8: ready/running

19、At time 37 P1: ready/running P3: ready/running P5: blocked suspend P7: blocked for I/O P8: ready/running At time 47 P1: ready/running P3: ready/running P5: ready suspend P7: blocked for I/O P8: exit -9- 3.4 = exponential growth of processes occurs - only a finite number of process IDs on systems - o

20、nly a finite amount of memory on systems however, since the size of created processes is small and since the OS has lots of swap space available = above code will most likely exhaust process table (run out of IDs) instead of run out of memory - most systems, OS will run out of process IDs and then e

21、rror “cant create a process“ user/root cant kill the malicious process (kill needs to create a new process) user/root cant ps the processes in the system (ps needs to create a new process) = only choice is to re-boot the system - some systems, OS will actually crash - some systems, user has a pre-sp

22、ecified limit on the number of processes he/she can create (a long-term scheduler) = user process wont be allowed to take the system down 3.5 We need to keep the process switch time as short as possible, so keeping the part of the OS that deals with context switches always in a fixed location in mem

23、ory (rather than bringing it in from disk every time or even on occasions), means that the OS instructions will execute faster and the process switch time will be predictable. -10- CHAPTER 5 CONCURRENCY: MUTUAL EXCLUSION AND SYNCHRONIZATION 5.1 Dispatcher 1 Get ptr to next process to execute Update

24、pointer Execute process Dispatcher 2 Get ptr to next process to execute Update pointer Execute process Execute the above sequentially - no problem with consistency Now interleave the first instruction on both dispatchers. The processors will execute the same process and one process will be skipped.

25、5.2 Mutual exclusion: If all three processes try to access the resource concurrently, two processes will enter Spagos due to AND criteria (i.e., sign can only be ONE value at a time). A social disaster! 5.3 1. Provide mutual exclusion? There are two cases to consider: a. A process is inside the crit

26、ical section and another tried to enter: Without loss of generality, assume Penelope is inside the critical section and Nicole tries to enter. Before entering the critical section Penelope sets her own flag to 1. When Nicole tries to enter the critical section she will see that Lope is up and will g

27、et caught in the while loop. Nicole will continue in the while loop until Penelope lowers her flag, which happens only at the end of the critical section b. Both are trying to enter simultaneously: In this situation, if both reach their respective while loop at the top, then the SIGN will ensure tha

28、t only one of them passes through. The SIGN is alternating between the two of them, and is only modified at the exit of a critical section. 2. No Deadlock? Suppose both are trying to enter simultaneously. In this case if the first is trapped into the while loop, then the SIGN will make one of the tw

29、o women lower her flag and go into a loop waiting for the SIGN to change (the inner while loop). The other woman whose turn is set by the SIGN will be able to get into Spagos. 3. No Starvation? Assume one is blocked inside the inner while loop, while the other is in the critical section In such a ca

30、se, if the one inside the critical section tries to re- enter, she will be blocked because on exit of the critical section she sets the SIGN to point to the other. Therefore, the one that just got out of the critical section will be forced to wait for her own turn. So, bounded waiting is taken care

31、of. 4. Progress? Suppose one of them is trying to enter with no competition: In such a case, the flag of the other is down, and thus she can enter. In summary, ALL requirements are SATISFIED -11- 5.4 The operation does not always cause a wait; when semaphore value is 0. NO actual waiting occurs 5.5

32、#include pthread_mutex_t countlock = PTHREAD_MUTEX_INITIALIZER; static int count = 0; int increment(void) pthread_mutex_lock( count+; if (count 5) printf(counter %d reached value 5, count ); pthread_mutex_unlock( return 0; pthread_mutex_unlock( return 1; int decrement(void) pthread_mutex_lock( while

33、 (count 5) printf(counter %d is 5:, count); count -; if (count =0) pthread_mutex_unlock( return 0; else pthread_mutex_unlock( return 1; 5.6 Identify processes: i. The generic teller process, parameterized by type (quick or normal service) and number ii. The generic customer service, parameterized by

34、 type (quick or normal service) and number Identify variables: quick: teller or customer is quick service number: number of the teller or customer tn: teller number to serve this customer ti: the ith teller cj: the jth customer Qserve: the current quick service customer to be served -12- Nserve: the

35、 current normal service customer to be served mutexQ: semaphore for mutual exclusion on queue computations The first two are part of each teller record, the first three are part of each customer record. The others are global. Identify events We could approach these from either the teller point of vi

36、ew, or the customer point of view. The latter is preferable, as each customer transaction is unique, while teller transactions are not. Hence we will not have to worry about synchronizing with the wrong event. A customer arrives in the bank and joins a queue A customer is called to the teller A cust

37、omer arrives at a teller window A customer completes a transaction and leaves the bank We create a semaphore for each of these (except the first: that is assumed to be outside our control), as part of each customer record. Write customer process We write this first, since the customer is the driving

38、 process for the tellers. The customer process is characterized by a) the type of customer (normal or quick), and b) the number of the customer class customer(Thread): def init(self,quick,number): self.quick=quick; self.number=number self.tn = 0 self.call=semaphore() self.customer_arrive=semaphore()

39、 self.transaction_complete=semaphore() def isQuick(self): return self.quick def run(self): self.call.wait() # wait for our turn goto_teller(self.tn) # teller number tn is our teller elf.customer_arrive.signal() # tell teller were here do_transaction() self.transaction_complete.signal() # tell teller

40、 were # not here leave_bank Write teller process The teller process is characterized by a) the type of teller (normal or quick), and b) the number of the teller class teller(Thread): def run(self,quick,number): global mutexQ,c,Qserve,Nserve while (1): mutexQ.wait() if quick: while Qserve j and not c

41、Qserve.isQuick: Qserve=Qserve+1 if not cQserve.isQuick: Nserve=Nserve+1; Serving = Nserve -13- else: Serving = Qserve else: while Nserve j and cNserve.isQuick: Nserve=Nserve+1 if cNserve.isQuick: Qserve=Qserve+1; Serving = Qserve else: Serving = Nserve mutexQ.signal() # “Now serving customer number

42、Serving“ cServing.tn = number # flag our number cServing.call.signal() # tell the customer cServing.customer_arrive.wait() # wait for her cServing.transaction_complete.wait() # and her transaction The if quick: . statement does all the queue calculations. We scan forward on the list of customers, lo

43、oking for customers of our type. If we find one, that is the next customer to be served. If there are none, then the next customer in the opposite type of queue is to be served. Since this is updating shared variables, it must be a mutual exclusion zone. write bank process (This is really the main p

44、rogram.) Qserve = 0 # customer number for quick service Q Nserve = 0 # customer number for normal service Q t = n*0 # list of tellers for i in range(1,n): # create and start all tellers if i k: ti = teller(1,i) # create quick service teller else: ti = teller(0,i) # create normal service teller tj.st

45、art() # start teller j = 0 # customer number c = # customer list while 1: # create and start customers forever j = j+1 x = random() if x QuickRatio: # QuickRatio is fraction of customers # wanting quick service c.append(customer(1,j) # create a quick service customer else: c.append(customer(0,j) # c

46、reate a normal service customer cj.start() # start customer # now customerj is implicitly on one # of the service queues wait_random_interval() # for next customer to arrive Add critical sections There is only one: the queue computation to see who is next to be served. Identified above by the mutexQ

47、 variable. -14- 5.7 The code for the one-writer many readers is fine if we assume that the readers have always priority. The problem is that the readers can starve the writer(s) since they may never all leave the critical region, i.e., there is always at least one reader in the critical region, henc

48、e the wrt semaphore may never be signaled to writers and the writer process does not get access to wrt semaphore and writes into the critical region. 5.8 a. For “x is 10“, the interleaving producing the required behavior is easy to find since it requires only an interleaving at the source language s

49、tatement level. The essential fact here is that the test for the value of x is interleaved with the increment of x by the other process. Thus, x was not equal to 10 when the test was performed, but was equal to 10 by the time the value of x was read from memory for printing. M(x) P1: x = x - 1; 9 P1: x = x + 1; 10 P2: x = x - 1; 9 P1: if(x != 10)

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 企业管理 > 管理学资料

本站链接:文库   一言   我酷   合作


客服QQ:2549714901微博号:道客多多官方知乎号:道客多多

经营许可证编号: 粤ICP备2021046453号世界地图

道客多多©版权所有2020-2025营业执照举报