Formal Models of Operating System Kernels phần 5 pps

The relationship between this process, the Swapper process, and the clock process is depicted in Figure 4.3 Swapping is performed by two main processes: one to select victims andanother

∧ lck.Unlock

∧ putDriverToSleep)

Proposition 94 The operation alarmsToCall implies that, if alarms = ∅,

∀ p : APREF | p ∈ domalarms
• alarms
(p) > now.

Proof By the predicate, alarms
= alarms \ pairs, where:

pairs = {p : APREF | p ∈ dom alarms ∧ alarms(p) ≤ now • (p, alarms(p))}

Therefore, on each call to alarmsToCall , it is true that:

∀ p : APREF | p ∈ domalarms
• alarms
(p) > now

Proposition 95 All swapped-out processes age by one tick when the clock

driver is executed.

Proof The critical schema is UpdateAllStorageTimes This is a component

of updateSwapperTimes.

The schema UpdateAllStorageTimes contains the identity

swappedout time
= swappedout time ⊕ {p
→ swappedout time(p) − 1}

Proposition 97 The current process’ time quantum is reduced by one unit (if

the current process is at the user level) each time the clock driver is executed.

Proof The body of the RunProcess operation in the clock driver

con-tains, as a conjunct, a reference to the schema sched UpdateProcessQuantum The predicate of this last schema contains the identity currentquant
=

Clock Process

Swapper Process

Alarms etc.

The relationship between this process, the Swapper process, and the clock

process is depicted in Figure 4.3

Swapping is performed by two main processes: one to select victims andanother to copy process images to and from a swapping disk

The swapper process is modelled by the following class The main routine

is RunProcess.

SwapperProcess

(INIT , swapProcessOut, swapCandidateOut, swapProcessIn,

swapProcessIntoStore , DoDiskSwap, RunProcess)

The following operation requests that a segment of main store be written

to disk It supplies the start and end addresses of the segment to be copied:

The next operation models the operation to read a segment into mainstore The name of the process to which the image belongs, as well as theaddress at which to start copying, are supplied as parameters The disk imagecontains the length of the segment.

pro-is unreadied The residency and start of swapout times for the process arethen cleared and the children of the selected process are then blocked Thestatus of the selected process is set to swappedout

Processes have to be swapped into store This operation is defined as:

∨ ((proctab.IsCodeOwner ∧ swapProcessOut)

∨ swapProcessOut))

When a process is to be swapped into main store, the following operation

is employed It determines whether the process has any child processes If

it has, it swaps the process into store and readies its children If the newlyswapped-in process owns the code it executes, it marks its code as in store andthen performs the swap-in operation If the process has no children, there is

no need to ready them; the rest of the operation is the same as just described

The doDiskSwap operation is the main swapper routine It determines the

process to swap in and then finds out whether it can allocate its image in free

store If it can, it just performs the swap If not, it determines whether it canswap some process out of store—that process should have an image size that

is at least as big as that of the process to be swapped in Once that candidatehas been found, the image size is determined and the swap-out operation isperformed; when the victim has been swapped out, the disk process is swappedinto store

∧ [mspec : MEMDESC ; start, end : ADDRESS; sz : N |

start = memstart (mspec) ∧ sz = memsize(mspec)

Proof By Proposition 54, since MakeUnready removes the process from the

ready queue and alters its state to pstwaiting 2

Proposition 100 When a parent process is swapped out, all of its children

Process

Disk Handler

Swap Disk Process

Swapper Process

Dezombifier

ISR

ISR

Fig 4.4 Interaction between clock, swap and dezombifier processes.

4.7 Process Creation and Termination

A major issue to be addressed is the following: how are processes createdwithin a system such as this? The answer is that some processes are created

at boot time, others when the system is running Among the latter class areuser processes In this section, mechanisms are defined for creating systemand user processes System processes come in two varieties, so two operationsare defined for their creation

Most system processes never terminate but user processes do, so a tive is defined to release resources when a user process ends; resource releaseincludes the handling of zombies For all of the system processes defined inthis chapter, termination is an exceptional behaviour

primi-The operations required to create processes (of all kinds) and to handlethe termination of user processes are all collected in the following class

The first operation to define creates a new process descriptor and adds it

to the process table In order to define this operation, the following functionsare required:

mkpstack :N1→ PSTACK

mpdata :N1→ PDATA

These functions are intended to simulate the allocation of storage for theclasses of structure A refined specification would fill in these details—for thepresent, the axiomatic definitions will suffice

The CreateNewPDescr operation just creates a new process descriptor.

It is supplied with the basic information required to create one through its

arguments The predicate creates descriptors for the new process’ stack anddata areas (using the above-declared functions) The identifier of the newprocess is also supplied as an argument The schema is somewhat uninterestingfrom the operating systems viewpoint; however, it does show how an Object-Zentity is dynamically created.

The operation CreateNewPDescr is, therefore, as follows:

pd Init[stat/stat?, kind?/knd?, prio/slev?, timequant?/tq?,

stk /pstack?, data/pdata?, mspec?/mem?, rqsz?/msz?]

pro-the system As part of this, a test (proctab CanGenPId) is made as to whether

the system has reached its maximum number of processes The schema is plicated by the fact that allocation might have to take place on disk and not inmain store It should be noted that the identifier of the newly created process

com-is returned by thcom-is operation; thcom-is will be of some importance, as will be seen

∧ rqsz = #code? + stacksize? + datasize?

If there are no free process identifiers and CanGenPId fails, an error should

be raised However, for the purposes of clarity, errors are ignored in this book.The case should be noted, however

In a similar fashion, a creation operation for system and device processesneeds to be defined There are some differences between it and the user-process creation operation In particular, all system-process identifiers andstorage areas can be predefined, so they can be supplied as configuration-time

or boot-time parameters The schema defining the operation is as follows:

There should be no errors raised by calls to this operation

The following operation writes a new process image to disk It will beloaded into main store by the swapper at some later stage This is the opera-

tion used above in the definition of the createAUserProcess schema.

It is now possible to continue with the definition of the interface operationsfor the creation of all three kinds of process The first operation is the onethat creates user processes This differs from the other two schemata in that

it requires locking and that it returns a new process identifier

CreateUserProcess=

∃ pprio : PRIO; tquant : TIME |

pprio = userqueue ∧ tquant = minpquantum • lck Lock

o(createAUserProcess[pprio /prio?, tquant/timequant?]olck Unlock)

The lock is required because:

• This is an operation that is called when other processes are executing.

• This is an operation that is intended to be called from user processes.

So, it is reasonable to ask, how are processes actually created? In particular,how is the first user process created? Without an initial user process, a processoutside the kernel that can call this primitive, how are user processes created?The answer is simple: there is a kernel call that creates the initial user process

The initial process is called the UrProcess and is created when the kernel

finishes its initialisation What is required is, then, the following:

CreateUrProcess=

∃ pprio : PRIO; tquant : TIME |

pprio = userqueue ∧ tquant = minpquantum • createAUserProcess[pprio /prio?, tquant/timequant?]

This operation requires stack and data region sizes to be created: they will

be zero or very small They are not specified because the UrProcess might

be used for purposes other than simply creating user processes (e.g., it couldcount them, exchange messages with them, and so on) For this reason, thestorage areas are not specified by the existential The operation also returns a

new process identifier (element of APREF ): it can be stored within the kernel

or just ignored

Child processes are created by the operation that is defined next It should

be noted that the basic operation is still createAUserProcess.

CreateChildUserProcess=

(∃ pprio : PRIO; tquant : TIME |

pprio = userqueue ∧ tquant = minpquantum • lck Lock

o(createAUserProcess[pprio /prio?, tquant/timequant?]

∧ proctab.AddChildOfProcess[rqprocid?/parent?, newpid!/child?])

olck Unlock)

Now come the two operations to create the two kinds of system processes

Both operations are based on the createASystemProcess operation This

op-eration performs the same role in the creation of system and device processes

as createAUserProcess does in the creation of user processes.

A difference between the two following operations and the ones for userprocesses is that the priorities are different System and device processes eachhave their own priority level They are assigned the appropriate priority bythe creation operation.

First, there is the system-process creation operation:

CreateSystemProcess=

(∃ kind : PROCESSKIND; prio : SCHDLVL |

kind = ptsysproc ∧ prio = sysprocqueue • createASystemProcess[kind/kind?, prio/prio?])

Next, there is the operation to create device processes:

CreateDriverProcess=

(∃ kind : PROCESSKIND; prio : SCHDLVL |

kind = ptsysproc ∧ prio = sysprocqueue • createASystemProcess[kind /kind?, prio/prio?])

The storage areas are defined by the kernel-configuration operation, and thecode is statically defined as part of the kernel code The following operationsare for use when processes terminate In the present kernel, user processesare the only ones that can terminate; all the other processes must continuerunning until the system shuts down

As noted above, the identifier of the process is also statically allocated

This allows, inter alia, the identifiers to be hard-coded into all

communica-tions (This will be of great convenience when IPC is defined in terms ofmessages, as they are in the next chapter, where a full interface to the entirekernel is defined.)

Next, it is necessary to handle process termination Processes cannot ply be left to terminate The resources belonging to a terminating processmust be released in an orderly fashion For this kernel, as it stands, processescan only hold storage as a resource, so this must be released before the processdescriptor representing the process is deleted In addition to releasing store,

sim-a process might hsim-ave unterminsim-ated children sim-and must, therefore, become sim-azombie before it can be killed off completely The following operations imple-ment the basics (and add a few extra operations to give the reader an idea ofsome of the other things that might need to be handled during termination)

If a process is on disk when it is terminated (say, because of system mination or because of some error that we have not specified in this chapter),its image must be erased The operation whose schema follows performs thatoperation

When a process terminates, its storage must be freed The following

schema defines what happens It is really just an interface to Block :

Finally, the full operation for releasing process storage is defined The way

in which storage is released will, at some point, depend upon whether the minating process owns its code or shares it with some other process Clearly, ifthe process owns its code, the store for the code can just be deleted—provided,that is, the process has only terminated children The basic operation for re-leasing storage is as follows It should be noted that there will be some extrawork for handling zombie processes

descriptor This choice has the consequence that any process in this kernel

can execute the operation just defined when it terminates

The operations just defined can be used to define the TerminateProcess

operation This operation is defined below

The operation uses a lock instead of a semaphore because, strictly speaking,

it belongs to the layer implementing the process abstraction

The termination operation also has to handle the case in which a ent process terminates before any of its children do If a parent terminates,its storage will be deallocated but this will also remove its code from mainstore Without code, the children cannot execute, so a mechanism must beimplemented to prevent the parent’s code from being deleted (If parents andchildren share data storage, it, too, must be prevented from deallocation.) Thezombie mechanism whose operations were defined together with the processtable is used to do this

par-Basically, when a parent process terminates, a check is made to see if thereare any active child processes If there are no active children, the parent isallowed to terminate normally Otherwise, the parent is unreadied and placed

in a special waiting state (which we refer to, here, as the “zombie” state)

When all the children of a zombie parent have terminated, the parent can be

deallocated (properly terminated) The deallocation is the same as for normalprocesses; each zombie must have a process descriptor, at least to record thelocations and sizes of its storage areas The only problem is that children cancreate children: in the model, this requires that the transitive closure of the

child relation be used to determine all the children of a parent process.

Proposition 101 When a process is swapped in, it enters the ready queue.

Proof The predicate of schema swapProcessIn contains MakeReady[p?/pid?]

Proposition 102 When a parent process is swapped out, none of its children

appear in the ready queue.

Proposition 103 When a parent process is swapped in, its children change

state and appear in the ready queue.

Proof The appropriate schema contains an instance of MakeReady 2

Proposition 104 When a device request is made, the current process enters

a waiting state and is no longer in the ready queue.

Proof In this kernel, there is really only one good case upon which tomake an argument: clock alarms When a process makes an alarm request,has its context swapped out by the SVC ISR and its state is set to pstwaiting

Furthermore, the ISR calls MakeUnready on the requesting process to remove

it from the scheduler The process is held by the clock driver

Device requests are made via SVCs, so the above will always hold 2

Proposition 105 When a device completes, the requesting process is

re-turned to the ready queue.

Proof Again, the clock driver is the only example but it is normative.When each process is awakened from its sleeping state (when its alarm clock

“rings”), MakeReady is called to return the process to the ready queue The MakeReady operation changes the status attribute in the process’ descriptor

to reflect the fact that it is ready (sets the status to pstready, that is) 2

Proposition 106 While a process is waiting for a device request to complete,

it is in neither the ready nor the running state It is in the waiting state.

Proof Proposition 104 states that the requesting process is unreadied bythe SVC ISR Therefore, it cannot be in the ready state The ISR also callsthe scheduler to execute another process, so the requesting process cannot be

Proposition 107 Processes marked as zombie cannot be swapped out.