Starvation: Difference between revisions
pc>Yuron No edit summary |
W81054ch [PHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+YnVyZWF1Y3JhdDxiciAvPmludGVyZmFjZS1hZG1pbjxiciAvPnN5c29wPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs) m (1 revision imported) |
(No difference)
|
Latest revision as of 10:03, 5 August 2019
Depends on | Processes • Resources |
---|
(Resource) starvation is often linked with deadlocks in that it can (potentially) cause progress to stop. However this is really more of a scheduling issue.
A process is ‘starved’ if it can’t get some resource(s) which it needs to proceed. This can be caused by other processes competing for (and winning) the resource.
Example: A printer spooler picks the next job by queuing users alphabetically: Aaron is happy with the service but Zachary has a long wait at busy times. This example is clearly fixable with a fairer scheduling algorithm, such as one based on a FIFO queue.
One of the possible resources is processor time. In an interactive system it is important that the process scheduler is able to give some time even to low-priority tasks. (They may get a smaller share than the higher priority processes.) Effective priority may therefore be raised as a process ‘ages’.
On the other hand, a real-time system should ‘finish’ all its pending jobs and go idle periodically, in which case this should guarantee starvation cannot occur. (As long as the assumptions are really true.)
Also refer to: | Operating System Concepts, 10th Edition: Chapter 5.3.4, pages 213 |
---|