Page 138 - DCAP103_Principle of operating system

Unit 4: Process Management-III

Notes
Figure 4.12: Resource-Allocation Graph with a Cycle but no Deadlock

processes that cannot run, and because more and more processes, as they make requests for
resources, enter a deadlock state. Eventually, the system will stop functioning and will need
to be restarted manually. Although this method does not seem to be a viable approach to the
deadlock problem, it is nevertheless used in some operating systems. In many systems, deadlocks
occur infrequently (say, once per year); thus, this method is cheaper than the costly deadlock-
prevention, deadlock-avoidance, or deadlock-detection and recovery methods that must be used
constantly. Also, in some circumstances, the system is in a frozen state but not in a deadlock
state. As an example, consider a real-time process running at the highest priority (or any process
running on a non-preemptive scheduler) and never returning control to the operating system.
Thus, systems must have manual recovery methods for non-deadlock conditions, and may
simply use those techniques for deadlock recovery.

4.6.7 Mutual Exclusion
The mutual-exclusion condition must hold for non-sharable resources. For example, a printer
cannot be simultaneously shared by several processes. Sharable resources, on the other hand,
do not require mutually exclusive access, and thus cannot be involved in a deadlock. Read-only
files are a good example of a sharable resource. If several processes attempt to open a read-only
file at the same time, they can be granted simultaneous access to the file. A process never needs
to wait for a sharable resource. In general, however, we cannot prevent deadlocks by denying
the mutual-exclusion condition. Some resources are intrinsically non-sharable.

LOVELY PROFESSIONAL UNIVERSITY 131