Formal Models of Operating System Kernels phần 6 pptx

Apart from its initialisation operation again, INIT, the process table exports operations to create the idle process CreateIdleProcess and to add and delete process descriptors AddProces

by elements of IPREF and whose elements are objects of type ProcessDescr The class also has state variable known procs to record the elements in the domain of procs; it is a record of the identifiers of those processes currently

in the system The variable freeids is a set of actual process identifiers that

represent those process references not currently referring to processes in thesystem The idea is that the identifier of a process is its index in the processtable

The kernel only allocates “actual” processes; that is, processes other than

the null and idle processes For this reason, freeids is a set of type APREF The procs mapping (table) is of type IPREF , the reason for this being that

the idle process is represented by a process descriptor that is allocated in theprocess table when the kernel is initialised

Apart from its initialisation operation (again, INIT), the process table

exports operations to create the idle process (CreateIdleProcess) and to add and delete process descriptors (AddProcess and DelProcess, respectively), as well as an operation to return the descriptor of a process (DescrOfProcess).

The operation to create the idle process could be defined in a higher layer

of the model Since the idle process owns no resources and executes a piece ofcode that will be supplied with the kernel (and whose address can, therefore,

be made available at kernel initialisation time), it seems reasonable to makeidle process creation a process table operation

ProcessTable

(INIT , CreateIdleProcess, AddProcess, DelProcess, DescrOfProcess)

procs : IPREF

→ ProcessDescr

known procs : F IPREF

(∃ pr : PRIO; stat : PROCSTATUS; stwd : STATUSWD;

emptymem : MEMDESC ; stkdesc : MEMDESC ;

memsz : N; ipd : ProcessDescr •

stat = pstready ∧ prio = pr ∧ stwd = 0 s

∧ emptymem = (0, 0) ∧ stkdesc = (0, 20) ∧ memsz = 0

∧ ipd.INIT [stat/stat?, knd/knd?, schdlv/slev?, tq/tq?,

stkdesc /pstack?, emptymem/pdata?, emptymem /pcode?, emptymem/mem?, memsz/msz?]

procs
= procs ⊕ {IdleProcRef
→ ipd})

The Context class implements the context-switching operations It is just

an encapsulation of the operations described in the previous chapter It is, inany case, relatively simple The reader should note the comments in the class

definition The operations defined in this class are extended by SwapIn and SwapOut —they are defined for convenience.

3.5 Priority Queue 71

3.5 Priority Queue

This kernel uses a priority queue as the core of its scheduler The PRIO type

is equivalent to the integers, so the priorities cannot be arranged as broadclasses as they are in the kernel modelled in the next chapter (where thereare three priority classes, each modelled by a separate queue) This kerneldoes not make assumptions about how the priority bands are defined, so

a representation has to be chosen to reflects this The representation is asequence of process references

Three relations are required for the definition of priorities They are theusual≤, ≥ and = operations The subscript is used just to differentiate them

from the corresponding relations over the integers

qprio : PREF

→ PRIO

procs : iseq PREF

dom qprio = ran procs

∀ p1, p2 : PREF •

p1∈ ran procs ∧ p2∈ ran procs ∧ qprio(p1)≤ P qprio(p2)⇒

(∃ i , i : 1 #procs • i ≤ i ∧ procs(i ) = p ∧ procs(i ) = p )

The class exports an initialisation operation (INIT), an enqueue and moval operations There is an emptiness test and a test to determine whether

re-a given process is in the queue A removre-al operre-ation, re-as well re-as re-a reorderingoperation, is also provided (the removal operation is used when re-prioritisingprocesses) The final operation that is exported returns the priority of a pro-cess that is in the queue

The reader will have noted that the priority record in the priority queueduplicates that in the process table What would happen in refinement is thatthe two would be identified

The enqueue operation is:

∧ ((qprio(pid?) ≤ P qprio(head procs)) ∧ procs
=

∨ ((qprio(pid?) > P qprio(last procs)) ∧ procs
= procs 

∨ (∃ s1, s2: iseq PREF | s1 s2= procs •

((qprio(last s1)≤ P qprio(head s2))∧

3.5 Priority Queue 73The operation uses the priority of the process in determining where the process

is to be inserted in the queue If the new process’ priority is greater (has a lowervalue) than the first element of the queue, the new process is prepended to thequeue; conversely, if the priority is lower (has a greater value) than the lastelement, it is appended to the queue Otherwise, the priority is somewherebetween these two values and a search of the queue is performed (by theexistential quantifier) for the insertion point

Proposition 21 The predicate of the EnqueuePROCPRIOQUEUE schema

satisfies the invariant of the PROCPRIOQUEUE schema that defines the state.

Proof Let I denote the invariant:

dom qprio = ran procs

Case 2 procs =   Let p s ={p : PREF | p ∈ ran procs
• qprio(p)} There

are three cases to consider:

i p is at the head of procs
—qprio(p) ≤ P min p s;

ii p is the last of procs
—qprio(p) > P max p s;

iii p appears in the middle of the sequence—i.e., min p s ≤ P (p q prio(p) ≤ P

max p s.

Case 2i Immediate

Case 2ii Immediate

Case 2iii Assume that there are two increasing sequences, s1and s2, of PREF s

s.t s1 s2 = procs Then, if qprio(last s1) ≤ P qprio(p) ≤ P qprio(head s2),

procs
= s1 ps2 By induction, s1and s2satisfy I , therefore s1 ps2

Proposition 22 If a process, p, has a priority, p r , such that, for any priority

queue, the value of p r is less than all of its elements, then p is the head of the

queue.

Proof By the ordering ≤ P , p r is less than all the elements of procs, i.e.,

p r ≤ P min p s , where p s ={p : PREF | p ∈ ran procs • qprio(p)}, as above.

Proposition 23 If a process, p, has a priority, p r , such that, for any priority

queue, the value of p r is greater than all of its elements, then p is the last

element of the queue.

When a process has executed, the next element has to be selected fromthe priority queue The operation to do this is:

NextFromPROCPRIOQUEUE

∆(procs, qprio)

pid ! : PREF

qprio
={pid!} −
qprio

The priority is updated as well as the sequence of queues

Proposition 24 If an element, p, has been removed from a priority queue

and the priority of p is p r , then p r ≤ head procs
.

Proof If p r   procs = procs
, then p

r > p s (where p s is as in Proposition

22) By the invariant, I ,

qprio(head procs) ≤ P qprio(head (tail procs))

⇒ qprio(head(tail procs)) = min p s

Therefore, qprio(head (tail procs)) ≥ P qprio(head procs) 2 The following pair of schemata define predicates The first, IsInPROCPRI- OQUEUE, determines whether the process, pid ?, is in the queue of processes.

The second is true when the process queue is empty

The following schema defines an operation to return the priority of the

process denoted by pid ?:

PrioOfProcInPROCPRIOQUEUE

pid ? : PREF

pprio! : PRIO

pprio! = qprio(pid ?)

3.5 Priority Queue 75

Proposition 25 For any pair of processes, p1 and p2, that are both in the

same priority queue, if p r,1 < p r,2 (where p r,i denotes the priority of process

1 or 2), then p1 occurs before p2 in the queue; otherwise, the order in which

they occur is reversed.

Proof This proposition is an immediate consequence of I 2 The unready operation, among others, requires that processes be removed

from the priority queue The operation to do this is modelled by the followingschema:

RemovePrioQueueElem

∆(procs, qprio)

pid ? : PREF

procs
= procs −  {pid?}

qprio
={pid?} −
qprio

There is the case in which a process’ priority is re-calculated at some time.Such a re-evaluation will affect the order in which the processes occur in thequeue For the following, as for all process priority queue operations, it isassumed that the priority value is established by a mechanism that is notdescribed by schemata in this section and that it is supplied to the operationreordering the queue upon re-calculation

It should be noted that the case in which more than one process’ priority is

re-calculated at a time does not cause any problems: if n processes have their priority re-calculated, n iterations of the reorderProcPrioQueue are required.

Usually, however, re-calculations occur one at a time

The following schema represents the desired operation:

∃ procs

: iseq PREF ; qprio

: PREF

→ PRIO •

procs

= procs −  {pid?}

∧ qprio

={pid?} −
qprio

∧ qprio
= qprio

∪ {pid?
→ newprio?}

This operation must, clearly, respect PROCPRIOQUEUE ’s invariant, so

we have the following:

Proposition 26 ReorderProcPrioQueue respects PROCPRIOQUEUE’s

There are three cases to consider:

i p? = head procs: this is clear;

ii p? = last procs: this is clear;

iii procs = s1 p?  s2: this is proved by induction.

It is clear that the composition implies the invariant 2

Proposition 27 If a process, p, is removed from a priority queue, P , its

priority, p r , recalculated, and returned to P to form P
, then:

1 If the length of P is exactly 1, P
= P

2 If the length of P is exactly 2, then p is either the first or last element of

P
.

Proof There are two cases

1 If p ∈ P and #P = 1, then P = p This case is covered by Proposition

37 (first case)

2 If P = p1, p2, then it follows that if p = p1, p ≤ P p2; otherwise, if p = p2,

p1≤ P p The result then follows by Proposition 21. 2

3.6 Current Process and Prioritised Ready Queue 77

Proposition 28 If a process, p, is removed from a priority queue, P , its

priority, p r , recalculated and is reinserted into P to form P
, provided that P

has more than one element, exactly one of the following holds:

1 If the new value of p r is less than the old one, p will appear closer to the

head of P
than in P

2 If the new value of p r is greater than the old one, p will appear closer to

the end of P
than P

3 If the new value of p r is the same as the old one, one of the two previous

conditions will hold.

Proof By Proposition 21 The interesting case is case 3, whose proof follows

Proposition 29 If a process, p, has priority, p r , is in a priority queue at

the nth position, if there are no processes of higher priority inserted into that queue, and if the priority of p is not recomputed, process p will have the highest priority after n processes have been removed from the queue.

Proof This is just an instance of the corresponding proposition for FIFO

Proposition 30 If a process, p, is at the nth position in a priority queue

and if m processes, each with priority higher than p, are added to the queue,

p will then occupy position n + m in the queue, provided that the priority of

p is not recomputed.

Proof Let procs = s1ps2with #s1= n By Proposition 21 (case 2iii),

s

1= s 1,1  s m  s 1,2 , where #s m = m, and s n are sequences of new processes,

where s=s 1,1  s 1,2 (More simply but less generally assume s

1= s1 s m.)

If #s1= n and #s m = m, and s1= s 1,1  s 1,2 and #s 1,1 + #s 1,2 = n, then

#(s 1,1  s m  s 1,2 ) = n + m Since qprio(p) remains constant, the proposition

3.6 Current Process and Prioritised Ready Queue

This is just a redefinition of CURRENTPROCESS so that the ready is placed by a priority queue The result is still called CURRENTPROCESS Structural theorems carry over from PROCPRIOQUEUE.

re-The class CURRENTPROCESS represents the scheduler in this

ker-nel The class contains a variable holding the currently executing process,

currentp, as well as the queue of ready processes (readyq, an instance of the

PROCPRIOQUEUE class) The class exports two schemata that manipulate currentp: CurrentProcess (which returns the value of currentp) and Make- Current (which sets the value of currentp) The operation MakeReady adds a

process to the scheduler’s queue; to do this, the priority of the process must be

supplied The ContinueCurrent is defined: it is, in fact, the identity relation and serves only to continue the execution of the current process The Suspend- Current operation removes the currently executing process but does not swap

in another process The schema for RunNextProcess defines an operation that takes the next element from the ready queue, ready, and sets currentp so that

the new process can be executed The operation defined by the schema called

SCHEDULENEXT is the primary interface to the scheduler.

Clearly, the scheduler needs to perform context operations It is also clearthat it should use locking to ensure exclusive access to data structures

CURRENTPROCESS

(INIT , CurrentProcess, MakeCurrent,

MakeReady , ContinueCurrent, SuspendCurrent,

3.6 Current Process and Prioritised Ready Queue 79

The MakeReady operation inserts a new process into the queue As can be

seen, the priority of the process must be used to compute the point where theprocess is to be inserted

As can be seen, ContinueCurrent is the identity:

This operation is used to remove a process from the readyq It can be used,

for example, when a process has to wait on a device queue

In this kernel, it is possible for a process to suspend itself It does so bycalling the following operation:

The RunNextProcess operation calls the scheduler and executes the next

process Note that it assumes that the context of the previously executing

process has been saved before this operation executes.

3.7 Messages and Semaphore Tables 81

selectIdleProcess

∆(currentp)

currentp
= IdleProcRef

This operation is required to ensure that the idle process runs when there is

nothing to execute in readyq.

Proposition 31 If currentp = p, for some process reference, p : APREF ,

then RunNextProcess implies that currentp
= p.

Proof The proof divides into two cases

Case 1 The ready queue is empty Therefore, by SCHEDULENEXT : readyqp IsEmptyPROCPRIOQUEUE ∧ selectIdleProcess

and currentp
= IdleProcRef follows immediately.

Case 2 The ready queue is not empty The following conjunction occurs in

the predicate of schema SCHEDULENEXT :

readyqp NextFromPROCPRIOQUEUE ∧ readyqp.MakeCurrent[p/pid?]

The operation NextFromPROCPRIOQUEUE removes the first element from

the ready queue This will, in general, be different from the current value of

3.7 Messages and Semaphore Tables

Semaphores have already been defined This kernel also requires asynchronousmessage queues (mailboxes), according to the requirements This section con-tains the outline specification for mailboxes

First, the message type is defined Messages are composed of data

(mod-elled by the atomic type MSGDATA) and a record of the message’s source (MSGSRC ).

The following (obvious) functions are defined to assist in manipulating sages:

The class that actually defines the mailbox type is as follows The mailbox

is defined in the obvious way as a queue of messages

The class exports operations to add a message (PostMessage) and obtain the next message from the mailbox (NextMessage) and an operation that determines whether there are messages in the mailbox (HaveMessages) The

initialisation operation just clears the queue of messages

lck Lockomsgs RemoveFirst[m!/x!]olck Unlock

Each process can have no more than one mailbox in this kernel (it does notneed more than one) This suggests that:

• An instance of GENTBL can be used to define and implement a central

table of mailboxes