If the check is favorable, that means that the system will remain
in a ???safe state,??? and the OS grants the resource request. Otherwise, the OS blocks the requesting process.
As appealing as the banker??™s blgorithm may be, it is not usually applied in practice, for several reasons.
Many times, processes do not know in advance what their maximum requirement for resources will be;
it depends on the results of the computation or the dynamic needs of the application. The number of processes
is not fixed, either; processes can be added to the mix at any moment, rendering previous calculations of
the safe state invalid. Likewise, the number of resources may change, as when a device fails or goes off-line
(e.g., a printer runs out of paper).
Deadlock detection
Some systems or subsystems (e.g., data-base systems) implement deadlock detection. This is different from
deadlock prevention and deadlock avoidance, which we have discussed and concluded are impractical in
general purpose systems. On the other hand, deadlock detection can be implemented with beneficial results in
some systems.
Deadlock detection works by having a deadlock detection routine run either periodically, or in response to
some circumstance (e.
Pages:
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306