tailieunhanh - Operating Systems Design and Implementation, Third Edition phần 2

Cách tiếp cận này nói chung là không hấp dẫn vì nó là không khôn ngoan khi cung cấp cho quá trình người sử dụng điện để tắt ngắt. Giả sử rằng một trong số họ đã làm, và sau đó không bao giờ quay trên một lần nữa? Điều đó có thể là sự kết thúc của hệ thống. | 4 Simpo PDF Merge and Split Unregistered Version - http memory without fear that any other process will intervene. This approach is generally unattractive because it is unwise to give user processes the power to turn off interrupts. Suppose that one of them did and then never turned them on again That could be the end of the system. Furthermore if the system is a multiprocessor with two or more CPUs disabling interrupts affects only the CPU that executed the disable instruction. The other ones will continue running and can access the shared memory. Page 72 On the other hand it is frequently convenient for the kernel itself to disable interrupts for a few instructions while it is updating variables or lists. If an interrupt occurred while the list of ready processes for example was in an inconsistent state race conditions could occur. The conclusion is disabling interrupts is often a useful technique within the operating system itself but is not appropriate as a general mutual exclusion mechanism for user processes. Lock Variables As a second attempt let us look for a software solution. Consider having a single shared lock variable initially 0. When a process wants to enter its critical region it first tests the lock. If the lock is 0 the process sets it to 1 and enters the critical region. If the lock is already 1 the process just waits until it becomes 0. Thus a 0 means that no process is in its critical region and a 1 means that some process is in its critical region. Unfortunately this idea contains exactly the same fatal flaw that we saw in the spooler directory. Suppose that one process reads the lock and sees that it is 0. Before it can set the lock to 1 another process is scheduled runs and sets the lock to 1. When the first process runs again it will also set the lock to 1 and two processes will be in their critical regions at the same time. Now you might think that we could get around this problem by first reading out the lock value then .