13.07.2015 Views

An Operating Systems Vade Mecum

An Operating Systems Vade Mecum

An Operating Systems Vade Mecum

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Nuts and bolts 1231 type2 ResourceClass = (Tape, Printer, ... ); { generic name of resource }3 ResourceIdentifier = integer; { specific name of resource }4 ResourceDescriptor =5 record6 Kind : ResourceClass; { set by process }7 Which : ResourceIdentifier; { set by resource manager }8 end;9 Resources = list of ResourceDescriptor;The service calls we provide might have the following form.GetResource(request). The request is of type Resources, with only the Kindfield set. If a process wants, for example, three tapes and a printer, it makes arequest with a Resources list containing four resource descriptors. When this callreturns to the calling process (perhaps after a delay), the Request list has beenupdated by the resource manager to indicate which resources have been granted.ReleaseResource(request). Again, request is of type Resources. The resourcemanager reclaims the resources listed.The standard scenario for a process that wishes to use some resources is as follows:GetResource(Request); { may block }Use(resource); { must terminate eventually }ReleaseResource(Request);If process A requests three tapes and a printer and the installation has five tapesand five printers, the resource manager will choose from these to give to A. When Alater decides to write information to the tape, it might submit a service call that looks likethis:Write(tape,info);where ‘‘info’’ is the data to be written, and ‘‘tape’’ is of type ResourceDescriptor anddescribes which tape drive to use. The Write call will fail if the tape has not been allocatedto process A. (We will discuss transput service calls in Chapter 5.) Likewise,ReleaseResource will fail if A tries to release a resource that has not been allocated.If a process terminates before it has released all its resources, the resource managerpretends that it has released them properly. This pretense is not as bad as preemption,because the terminating process cannot be hurt by taking away its resources. However,the resources may not be in a consistent state. The resource manager could just trustprocesses to leave resources in the right condition. For example, a tape drive should berewound. It is better for the resource manager to handle this finalization part of therelease operation itself, whether release was performed explicitly by the process or implicitlyby the termination of the process. But the internal consistency of some resources,like files, cannot be enforced by the resource manager because it does not know how thefile is interpreted by the processes that use it. The concept of atomic transactions, discussedin Chapter 6, can be applied to achieve proper finalization even in the case offiles.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!