An Overview of Process Management in the RHODOS System 1

Transcription

1 An Overview of Process Management in the RHODOS System 1 Damien De Paoli and Andrzej Goscinski (ddp@deakin.edu.au, ang@deakin.edu.au) School of Computing and Mathematics Deakin University Geelong, Victoria 3217 September 8, 1994 Abstract This report presents the research into process management in RHODOS. It details the types of processes RHODOS supports. Also covered are the policies that dictate the states the processes can exist in and the events that cause transitions between these states. A mechanism to enact the abovementioned policies was created. This mechanism embodied in a kernel server called The Process Manager, manipulates the processes, and the queues they are in; and supports operations that allow the transitions between these queues. The internal workings of the process manager are presented including how concurrency is achieved. Following this, the operations that the process manager offers to support process management is presented. Finally, as process migration and remote process creation exist within RHODOS, the required support for these services is discussed. Keywords: Distributed Systems, Distributed Operating Systems, Process Management. 1. This work was partly supported by the Australian Research Council under Grants A and A , and Deakin University Research Grant

2 1 Introduction The RHODOS architecture (Figure 1) consists of firstly a hardware dependant section encapsulated into the microkernel and secondly processes running in user mode. These processes consist of kernel servers, system servers and finally user processes. The process manager is a kernel server as it manipulates data that is stored within the microkernel. User Mode Processes Network Manager Memory Manager Migration IPC Manager Kernel Managers Process Manager Name Server Trading Server File Server/Agent Data Collection VDU Server TTY Server System Servers Library Calls Interface Global Scheduler Authentication User Processes System Calls Interface m Kernel Local IPC hardware errors Exceptions Port Control Process µ Kernel Page Control Control Data Collection int 3 int 5 int 6 int 7 software Ethernet Driver Context Switching Serial Driver Clock Traps Figure 1 RHODOS Architecture The job of the process manager is to manage the processes that are created in RHO- DOS. Each process created in RHODOS can request operations from the process manager to create a twin of a process (thus, creating a child process), to wait for a child process to exit, to kill off a child process, to stop executing. Another job of the process manager is to clean up after a process has causes a hardware exception, e.g. a division by zero error. The process manager cleans up by terminating the process, freeing up resources etc. As RHODOS is a distributed operating system, the process manager must be capable of dealing with remote requests. For example, if a parent creates a child process which is then migrated to a remote host (or is statically allocated to a remote host), the process manager must be able to deal with a parent waiting for a remote child to exit. To demonstrate how the above issues have been resolved this report is organised as follows. Kernel Manager interaction and the role of the process manager in presented in Section 2. Section 3 details the types of process in RHODOS. Section 4 presents the states of the processes and the transitions between the states. In Section 5 the process table the process manager uses to keep track of all the processes and their state is presented. Section 6 details the state table system that the process manager uses for concurrency. The initialisation of the process manager is presented in Section 8. Section 9 goes through (in detail) each of the process operations the process manager supports. Section 10 looks at the problems generated when a process can execute remotely (whether through migration of initial placement). Finally Section 11 concludes this research. 2 Kernel Manager Interaction The RHODOS kernel managers are responsible for the management of the basic logical resources of a distributed system: processes and processor time, remote communication, 2

3 memory, devices and network delivery protocols. Though each kernel manager is responsible and performs specific functions, they interact following the master - slave model. The process manager is a master of the remaining managers, which do not interact with each other. This model of interaction has been selected to allow the process manager to control allocation of resources to each new and existing process. All process management is provided by the process manager, and is accessed via a set of library calls. Each library call is a simple stub of code that forwards a request along to the process manager. Once the process manager receives this request, it determines what action needs to be performed. The example of requesting a twin of the current process illustrates the way in which the kernel managers interact. Figure 2 details the resources the kernel managers control, and the interaction required to create a twin of a process. USER PROCESS process_twin() PM PCB #1 PCB #2 SM SPACE #1 SPACE #2 TTY VDU DM FM FILE #1 FILE #2 Figure 2 Kernel Manager Interaction for twinning a process Firstly, the user process requests the process twin by using the library call. This sends a request to the process manager to twin the current process. The process manager then copies the appropriate information relating to the process (the state it is in, accounting data etc.). This information is stored in a Process Control Block (PCB). Then the Process Manager (PM) requests the Space Manager (SM) to copy the spaces (the name of the space is stored in the PCB, thus the PCB is passed to the Space Manager along with the request). Next the Process Manager would request that the Device Manager (DM) handle the devices for the new process. The Process Manager requests that the File Manager (FM) allow the new process to have access to the open files of the process that is being twinned. Each of these managers replies back with either a success or failure to the process manager indicating that the resources are available for the new process. Finally, the Process Manager replies back to the user process with either success or failure as appropriate. 3 Process Types and Process States There are two types of processes within RHODOS [3]. Firstly, there is a heavyweight process, i.e., each process has a separate data and stack space, whilst sharing its text space with another process (a Unix process belongs to this class of processes). The second type of process is a mediumweight process, which has a separate stack space, whilst sharing its text 3

4 and data space with another process. All RHODOS processes must exist within one of five separate states (Figure 3). Firstly, there is the ready state. All processes that are about to execute are said to be in a ready state. A process is dispatched to a run state from the ready state. The run state is where all processes are actively executing. Once a process has finished its time slice, it is placed back into a ready state (Note that all process scheduling and de-scheduling is performed within the micro-kernel, and as such is outside the scope of this report). However, if a process actively executing (i.e., in a run state) issues a recv, call or sleep function, then the process is placed into a blocked state. The recv and call functions block on a port waiting for a message. Whilst the sleep call blocks until a specified time has passed. Zombie kill kill exit kill Frozen Run migrate_in recv / call / sleep migrate_out dispatch finish time slice Ready Blocked Interrupt / timeout / message pair up Figure 3 Process State Transitions When a message is sent to the port of a process which is in a blocked state (i.e. the process issued a recv or call) then the message is paired up with the recv function and the process state is changed to ready. Both the recv or call functions can have a timeout value associated with the function (i.e. the recv or call function should only wait for a message for a specified time). Thus, if this timeout occurs, then the process s state is changed back to ready with the result returned to the recv function indicating a timeout has occurred. A process can also change state from blocked to ready when an asynchronous interrupt occurs. For example, when a key is pressed an interrupt occurs, which subsequently unblocks the serial device handler to take the appropriate action. The frozen state is used by the process migration manager [2]. When a process is about 4

5 to be migrated, the migration manager places the process into a frozen state (by use of the migrate_out function). Once a process has been successfully migrated and is ready to be restarted on its new host, a migrate_in function is issued, which changes the state of the migrated process from frozen back to ready. Finally, when a process issues a process_exit(), it changes its state to zombie. The zombie state can also be reached if a parent process issues a process_kill() to a child process, from either the ready, run, frozen or blocked states. 4 Process Queues All processes in RHODOS exist within the aforementioned five states. Theses states are represented by five queues within the process manager: Ready, Run, Blocked, Zombie and Frozen. Each queue consists of two pointers: head and tail. The head and tail pointers both point to a pcb structure and each pcb structure uses next and prev pointers to link with the other pcbs in the queue (Figure 4). Queue Head Tail Prev PCB Prev PCB Prev PCB Next Next Next A function called pcbqueuetransfer is used to change a process queue: PCB *pcbqueuetransfer( ptr, queue ) PCB *ptr; uint16_t queue; The parameters passed to pcbqueuetransfer detail which queue to transfer a particular pcb (ptr) to. Each pcb has an integer field (queue) indicating which queue it is in, and by use of this field the transfer procedure dequeues the pcb from the appropriate queue and enqueues the pcb on the queue requested. The pcb dequeue and enqueue functions exist in a critical region, and hence all interrupts are masked out whilst these functions are executing. 5 Process Table Figure 4 Queue Structure in RHODOS The heart of the process manager is its process table. This table keeps track of which processes are currently running on the same host, their state, exit values etc. The table is a linked list, with each node of the list representing a process. The contents of the process table are shown in Figure 5. An SNAME is a structure that uniquely identifies any object in RHODOS. Therefore, the SName (or identification) of the process is stored in the field process. The process control block (PCB) is pointed to by pcb. If a process exits and its parent is not waiting for its exit 5

6 value, then exit_value holds its exit status. The field parent stores the SName of the parent process. The state field indicates what state the process is in, e.g., Active, Exited etc. The enumerated type proc_state lists all the possible states allowed. A brief explanation of the state Nucleus is that it allows the process manager to keep track of orphaned child processes. The use of the Nucleus state is explained more fully in Section 8. enum proc_state {Nucleus, Active, Exited, Waiting, Frozen, Migrated, Stat_allocated}; struct entry { SNAME process; PCB *pcb; int exit_value; SNAME parent; enum proc_state state; struct entry *next; struct entry *parent_entry; struct entry *first_child; struct entry *brother; }; Figure 5 Contents of the process table The next four fields maintain the links between the processes. Firstly, the next pointer indicates the next process in the table. The parent_entry field points to the process table entry of a parent s process. The first_child pointer is a link to the first child of a given process. All subsequent children are linked using the brother pointer as shown in Figure 6 Process 1 next first_child Process 2 brother parent_entry Process 3 NULL Process 4 NULL Figure 6 Structure of the process table 6

7 6 Server Concurrency Simply having the process manager handle process management (with the use of the process tables) does not allow a fully concurrent server. An example of this is when a process requests a twin. Firstly the process manager receives the request, starts processing it, requests the memory manager to handle the memory copying/sharing for the twin. At this point the process manager waits for a response from the memory manager. Thus, the process manager has stopped execution, and if a new request came in it would not handle it until the memory manager had replied, and the twin operation completed. The process manager therefore can be idle whilst incoming requests are waiting to be processes. Note that this idle period only occurs when the process manager wishes resources that it does not control. To remove the idle period and hence to provide a fully concurrent server a state table was needed. This table keeps the state of each request the process manager handles. If a requested operation requires external resources, then both the initial request and subsequent requests for the external resources are logged into the state table. At this point the process manager can continue to execute and handle any more incoming requests. When the external resource is passed to the process manager, it can look up the state table and determine which external resource(s) have been granted and subsequently to which operation the resource belongs. This enables the process manager to restart the initial operation and complete it if all the required external resources have arrived. Thus, the state table system enables the process manager to be a fully concurrent server. 7 State Table The contents of the state table system used to provide concurrency are detailed in Figure 7. In essence, the state table is a doubly linked ordered list. The ordering is based on the sec and usec fields. RHODOS IPC primitives [4], allow a timeout to be associated with a receive operation. Thus, a process will wait for up to a given time for a message to be received. This receive timeout is measured in seconds and/or microseconds. Hence, the sec and usec fields, in the state table are used to associate a timeout (by use of the IPC primitives [4]) with a particular operation. The sec field is measured in seconds, whilst the usec field is measured in microseconds. The head of the list is the entry which has the smallest timeout value, whilst the tail of the list has the largest timeout value. enum oper_type { Process_twin, Process_exit, Process_kill, Space_share, Space_duplicate, Space_free }; typedef struct state_table { int32_t sec, usec, messno; SNAME who, child; enum oper_type operation; } ste; SPACE **addr; struct state_table uint32_t num_in_subq; *next, *prev, *parent, *subq, *next_in_subq; Figure 7 Contents of the state table 7

8 The components of the state table are firstly who and child. Who is always the SName of the process that has requested an operation from the process manager. Child is the SName of a child process when the operation is a process_twin(). These SNames are needed so that both the child and parent can be informed of the result of the process_twin() operation. The operation field indicates what operation this entry relates to. The list of operations are shown in the enumerated type oper_type. The next field, addr, is a pointer to the address of the space that needs to be changed after a space_share() or space_duplicate() call is made. For example, when the memory manager shares/duplicates a space, it returns a pointer to that space, and the addr indicates the address in the PCB structure that should be set to the newly shared/duplicated space. The messno field is a unique identifier that relates each message that is sent out to each state table entry. For instance, every time a message is sent out, e.g. a space_duplicate for a process_twin request, then messno is sent along with the usual parameters to space_duplicate. Then once the memory manager replies back with the result from the space_duplicate it also returns messno. Thus, the process manager can use messno to identify which space_duplicate the reply relates to, and hence which process_twin it is associated with. NULL prev State Table Entry (Head) subq parent parent parent sub entry next_in_subq sub entry prev next_in_subq sub entry next next_in_subq NULL State Table Entry next prev State Table Entry (Tail) next NULL Figure 8 Structure of the state table 8

9 The next and prev fields, respectively, indicate the next and previous state table entries. The parent and subq pointers allow each entry to have associated with it several other entries contained in a subq, all linked by the next_in_subq pointer, as shown in Figure 8. The last field, num_in_subq, is used to indicate how many entries are in the subq. To illustrate why this structure was used a look at how a process_twin request is dealt with. When a process_twin() request is received a parent state table entry is created. Within this parent entry s subq is stored a state table entry for each space_share() and space_duplicate() request. When a reply about a space share/duplicate is received, the number of entries in the subq is decreased. This continues until there are no more entries in the subq (i.e., num_in_subq = 0) and then the parent entry (in this case the one relating to the process_twin operation) can now be consulted to indicate whom the replies can be sent to (who and child). 8 Initialisation Once the process manager starts executing, it must initialise the state table to be empty. As one of the basic premises of the process manager is that every process will have a parent, this seems fairly self evident, however there is no parent process for the processes downloaded at boot time; a parent must be available for these downloaded processes. These processes are therefore considered to have the nucleus as their parent. Hence, the Nucleus state in proc_- state (Figure 5). This solution also allows consistent management of orphaned processes. As instead of having no parent at all, the parentage can be inherited by the nucleus. Then, when a process exits, its parent can be checked. If the parent is the nucleus, then the process manager can remove all knowledge of the exiting process, because its exit value is not going to be retrieved, as the process parent has already finished. The second stage of the initialisation is therefore to initialise the process table to have only the nucleus in it as a process. The next step is to issue a recv (receive) on its well known port waiting for a message to come in. The recv will pick up an advise message from the nucleus. This type of message advises the process manager that one or more processes were down-loaded with the boot image. (There will always be at least one, as the process manager itself must have been down-loaded with the boot image). This allows the process manager to keep track of processes that exist, but were not created using the process manager s primitives. If more advise messages have been sent, these are dealt with, until finally the process manager blocks on its well known port (i.e. no more messages are available to be processed). The process manager is then waiting for requests to be sent from other processes. 9 Process Management Primitives The process manager provides seven primitives: process_create, process_twin, process_wait, process_exit, process_kill, process_freeze, and process_exception. 9.1 process_create process_create( file, argv, envp ) SNAME *file; char *argv[], *envp[]; 9

10 Once a process_create primitive is received, the process manager informs the memory manager that a process is being created, and that a new set of spaces are to be created (Text, Data, User Stack and System Call Stack) from the file specified. The device server and/or file agent must be informed of what the created process standard in, standard out and standard error are. Note that this information will be supplied by using the environment pointer envp. The process create primitive requests the nucleus to create a new PCB structure and the ports associated with the process. The argv variable specifies the run time parameters to the new process. As one of RHODOS goals is to utilise load balancing both dynamic allocation (process migration) and static allocation (remote process creation) must be services the process manager provides. For a detailed discussion of process migration see [2]. The interaction between the RHODOS servers to provide remote process creation is presented in Figure 9. With a remote process creation, the global scheduling server is consulted to determine the destination for the remote creation. Then the local file agent and device server are notified of the new process remote creation. This enables the local file agent to inform the remote file agent of all open files that the process has access to. The local file agent then removes all knowledge of the new process. The local Device Driver informs the remote device driver of the new process. This means both the local and remote Device Drivers maintain information for the new process. Then the process_create request is forwarded on to the remote process manager. This remote process manager then requests a PCB and the required ports from the nucleus, requests the memory manager to handle the creation of the required spaces and lastly informs its local file agent, and device server of standard in, standard out and standard error. Source Host Destination Host User Process Memory Manager Global Scheduling Server process_create Create spaces Process Manager Decide destination Process Manager Forward process_create request File Agent Notify of standard File Agent in, out and Device Server error Notify of Device Server standard in, out and error Figure 9 Communication paths for remote process creation 10

11 The processing steps and messages required for process_create() are as follows: Step 1 The process manager receives a process_create request and: determines who is requesting the process_create; retrieves standard in, standard out and standard error from envp; allocates a new PCB via the nucleus. allocates the required ports via the nucleus. Step 2 Having completed Step 1 the process manager: creates a state table entry that registers the process_create operation; creates a new state table entry (a sub entry of the create state table entry) sends a request (Create_M1) to the local memory manager for a space_create_spaces(). In addition to this a unique message number (message_no) is sent, so that the reply can be matched up to the process_create operation: Create_M1: Process Manager Memory Manager: { space_create_spaces ( which_process, message_no) } Step 3 The process manager then: informs the Device Server and/or File Agent of the process standard in, standard out and standard error. Note that if the process is created remotely this message would also indicate this. Step 4 If the process create is to be a remote creation then: the location for the new process is retrieved from the global scheduler; the process_create request and a unique message number (message_no) is forwarded (Create_M2) to the remote process manager: Create_M2: Local Process Manager Remote Process Manager: { process_create ( which_process, message_no) } Note that the remote process manager would then: perform Step 1 perform Step 2; perform Step 3; perform Step 5. Step 5 The local process manager then: sends back the result of the process_create primitive, the SNAME of the new process on success. On failure, the return value indicates an error and the type of error that occurred. It should be noted that at the present time the file server for RHODOS is not sufficiently advanced for us to implement and test process_create(). 9.2 process_twin process_twin( mwp, shared_port ) 11

12 int mwp; PORT *shared_port; The process_twin primitive works in a similar manner to the process create primitive. It calls the nucleus to get a PCB and the required ports, informs the device server and/or the file server that the child process should be connected to the same standard in, standard out, standard error and any open files that the parent has. If the flag mwp (mediumweight process) has a value of one, then a mediumweight process will be created, otherwise a heavyweight process will be created. A mediumweight child process shares both the text and data spaces with its parent, whilst having a separate stack space. If a heavyweight process is chosen for the twin (indicated by the flag mwp having a zero value), then the shared_port field can be used to specify a port on which both processes may share incoming communication. When a pair (or more) of heavyweight processes utilise a shared_port, then they are called a team. The processing steps and messages required for process_twin() are as follows: Step 1 The process manager receives a process_twin request and: determines who is requesting the process_twin; retrieves whether the twin is to be a heavy or mediumweight process; retrieves whether there is a shared_port; checks parameters to see if they are valid; allocates a new pcb via the nucleus. If either of the last two operations fail (i.e., incorrect parameters were passed, or no more PCB structures could be allocated) then the process_twin operation returns an error. The parent is then informed of the failure of the process_twin() (with errno set to the appropriate error value). Step 2 The process manager: copies the execution state information (e.g. registers, priority etc.); copies across the accounting information (e.g. system and user time, etc.); creates the hidden and unique ports (via the nucleus). Step 3 Having completed both Steps 1 and 2, the process manager: creates a state table entry that registers the process_twin operation; creates a new state table entry (a sub entry of the twin state table entry) that indicates a request for a space_share() has been sent to the memory manager on behalf of the process_twin operation; sends a request (Twin_M1) to the memory manager for a space_share() of the text space of the process. The parameters of the message indicate which space of which process to share. In addition to this a unique message number is sent, so that the reply can be matched up to the process_twin operation: Twin_M1: Process Manager Memory Manager: { space_share ( which_process, which_space, message_no) } creates a state table entry. If the process_twin() specified a heavy-weight process (mwp = 0), then a space_duplicate() entry is created. Whereas, if mwp was set to 1 (a medium-weight twin), then a space_share() entry is created; 12

13 sends a request (Twin_M2) to the memory manager for either a space_- share() or space_duplicate(): Twin_M2: Process Manager Memory Manager: { space_share / space_duplicate ( which_process, which_space, message_no) } a space_duplicate() state table entry is created for the stack space; sends a request (Twin_M3) to the memory manager for a space_duplicate(): Twin_M3: Process Manager : { space_duplicate ( which_process, which_space, message_no) } issue receive on well known port, and block until the memory manager replies. Step 4 When the memory manager replies to the process manager, the process manager: uses the message_no to determine which space operation this is a reply for, and therefore which process_twin operation it relates to; removes this sub-entry from the twin state table entry; if all of the sub-entries of the twin state table entry are removed (i.e. the memory manager has duplicated/shared all the spaces required), then the parent and child are notified of the result of the process_twin() operation. The parent receives back the child s pid if the process_twin was successful, whereas the child receives back a pid value of 0; however, if one of the space operations fails, or a timeout occurs before the result of the space operations are received, then the process_twin() operation fails, and the parent receives a child_pid value of -1, with errno set to the appropriate error number; If the process_twin operation was successful, send message Twin_M4 to the child with a pid of 0 and errno of 0 indicating no error has occurred: Twin_M4: Process Manager Child Process: { pid=0, errno=0 } remove all state table entries relating to the process_twin(); issue receive on well known port, and block until a new request comes in. 9.3 process_wait process_wait ( ) The process_wait() primitive takes no parameters. It allows a process to wait for a child to exit. If a child process has not finished, then the parent is placed on the wait queue. If, however, a child process has exited then the process_wait() primitive returns that child s exit value. The computations that are conducted when a process_wait() request is issued are as follows: Step 1 Determine the process who issued the process_wait(). 13

14 Step 2 Check to see if there is a child of this process who has already exited: If there is no child who has exited: place the parent process on the wait queue; change the parent process state (in the process table) to Waiting. If there was an exited child: retrieve the child s exit value from the process table; remove the child s entry from the table, and all links to it (parent, siblings); return the child s exit value to the process who issued the process_wait(); issue receive on well known port, and block until a new request comes in. 9.4 process_exit process_exit ( status ) int status; The process_exit primitive is passed a status, which is the exit value of the process. Once a process exits, there are resources to free. Firstly, the process manager can inform the device server and/or file server that all open files and standard in, standard out and standard error should be closed. Secondly, the memory manager can be informed to remove all spaces associated with the exiting process. Thirdly, process exit requests the nucleus to remove all the data structures associated with the process (the PCB and ports). Finally, if no parent is waiting for its return value currently, then the process manager transfers the process to the zombie queue. The steps and messages required for process_exit() are as follows: Step 1 Determine which process issued the process_exit(). Step 2 Clean up the process table by: finding all the children of this process and removing them (as their parent is exiting, no one is interested in their exit value); change the state of the exiting process in the table to Exited; record the exit value in the process table. Step 3 Check to see if the exiting process parent process is waiting for a child to exit, if so: change state of parent process to Active; send to the parent process the child s exit value. Step 4 Free up the resources associated with the exiting process by: de-installing the process pcb (via the nucleus); creating a state table entry for a process_exit(); For each space of the process create a sub state table entry for each space_free(); send Exit_M1 to the memory manager, requesting a space_free(): Exit_M1 Process Manager Memory Manager: { space_free ( which_process, which_space, message_no) } issue receive on well known port. Step 5 At some point the memory manager replies back, and the process manager: 14

15 looks up the state table to find which sub entry the message_no received matches and thus, which space_free() and process_exit() this reply is associated with; and removes the sub entry from the exit state table entry. If all the sub entries of the exit state table entry are removed (hence all the spaces have been freed by the memory manager) then: deallocate all ports owned by the exiting process (via the nucleus); transfer the process pcb to the free queue; remove all state table entries relating to the process_exit(); issue receive on well known port, and block until a new request comes in. Note that as the process wishes to exit, no reply of success/failure is sent back to the process. 9.5 process_kill process_kill ( which ) SNAME *which; The process_kill() primitive allows a process to halt another processes execution. Thus, the parameter which identifies the process to be terminated is passed in, resolved and the specified process is terminated. The steps and messages required for process_kill() are shown below: Step 1 Determine which process is to be killed by: looking up the local process table for the process identified by which Step 2 Clean up the process table by: finding all the children of this process and removing them (as their parent is exiting, no one is interested in their exit value); change the state of the killed process in the table to Exited; record a zero exit value in the process table. Step 3 Check to see if the killed process parent process is waiting for a child to exit, if so: change state of parent process to Active; send to the parent process the child s exit value of zero. Step 4 Free up the resources associated with the killed process by: de-installing the process pcb (via the nucleus); creating a state table entry for a process_kill(); For each space of the process create a sub state table entry for each space_free(); send Kill_M1 to the memory manager, requesting a space_free(): Kill_M1 Process Manager Memory Manager: { space_free ( which_process, which_space, message_no) } issue receive on well known port, and block until the memory manager replies. Step 5 At some point the memory manager replies back, and the process manager: looks up the state table to find which sub entry the message_no received 15

16 matches and thus, which space_free() and process_kill() this reply is associated with; and removes the sub entry from the kill state table entry; If all the sub entries of the kill state table entry are removed (hence all the spaces have been freed by the memory manager) then: deallocate all ports owned by the exiting process (via the nucleus); transfer the process pcb to the free queue; remove all state table entries relating to the process_kill(); send Kill_M2 to the process who requested the process_kill() that it either succeeded/failed: Kill_M2 Process Manager { child_pid, errno } Process who issued process_kill(): issue receive on well known port, and block until a new request comes in. Note that the only way process_kill() can fail is if the memory manager does not reply to the space_free() requests before a timeout occurs. 9.6 process_exception process_exception( ptr ) PCB *ptr; This function is invoked by the Nucleus when an exception occurs whist running a process. Possible causes for the exception are segmentation faults, bus errors, arithmetic exceptions, etc. These exceptions are unrecoverable, thus, the process manager looks up the process standard error (by using the ptr field), sends a message to it indicating an exception has occurred and of what type it is. From this point, the process manager can invoke process_kill, effectively transferring the process from the ready queue to the zombie queue and freeing up the resources associated with the process. As all the process_exception() primitive performs is a print of the error message and then a process_kill() (detailed in the above Section 9.5), the algorithm is not shown in this report. 10 Resolution of remote process_wait(), process_exit() Due to the RHODOS system utilising process migration and remote process creation, it is quite possible that a parent process and a child process reside on different machines throughout their lifetimes. This can cause a problem when the parent process issues a process_wait() and the child process resides on a remote host, as the exit value of the child cannot simply be passed to the parent. Thus, the parents origin node will manage all process exits and waits issued from the parent and its children. This solution is shown in Figure 10. In Figure 10, a process was first created (or twinned) on host A, as this process is about to twin a child process, it is denoted the parent process. After the parent process has run on host A for a while, it is then migrated to host B. The parent process then twins off a child process. After both executing on host B, the parent process is migrated to host C and the child process is migrated to host D. At this point, the child process exits. This value is passed to the process manager on host D, which identifies that the parent is not on host D, and therefore sends the exit value to the origin of the parent process (this value is stored in the PCB). Thus, when the parent pro- 16

17 cess issues a process_wait() to host C s process manager, which identifies that the child process is not on host C, and sends an remote procedure call to the parent process origin (host A) for the child s exit status. Host: A Host: B Process Manager Process Manager Host: C process_wait() process_exit() Host: D Process Manager Process Manager Parent Origin: A Child Origin: B Figure 10 Resolving a remote process_wait() / process_exit() 11 Conclusion This report has taken the results of [1] and extended the process model from the proposed three states and extended this to the current five state model. This five state model allows the full functions of process management and includes the capability for process migration and remote process creation. A process table was utilised, that allowed the RHODOS process manager to manipulate the states of processes, and manage all the parent / child process interactions. This table also allowed resolution of parentless child processes (orphaned processes). To have a useable, efficient process manager it was evident that the it would have to be fully concurrent, i.e. be able to handle multiple requests without blocking. This was solved by creating a state table entry system. Moving the process management routines outside of the micro-kernel created another problem. All processes that are downloaded at boot time have to be registered. This was formerly performed by simply executing the appropriate routine within the micro-kernel. Unfortunately, the process manager is itself one of the downloaded processes, thus the routines could not easily be invoked. The process manager overcame this by having the micro-kernel inform the process manager of the processes downloaded at boot time. Once the process manager started to execute, it received these messages and placed the relevant information into the 17

18 process table (including details about itself). The process manager supports seven functions: process_create, process_twin, process_wait, process_exit, process_kill and process_exception. These functions allow the process manager to manipulate the processes and their states to conform with the process states required. Finally, the support of process migration and remote process creation requires some careful consideration as not all process details are local to a machine. Pointers cannot be used to local resources if the process can be migrated remotely. An obvious example of this is the parent child interaction. The relationship between these processes must be expressed in a non location dependant form, so that pairing up of a parent s process_wait and a child s process_exit can be performed. By utilising the original host of all processes as a common contact point, we solve this problem in an efficient manner. Acknowledgements We would like to thank Michael Hobbs, Raj Mohan Panadiwal and Greg Wickham for their help in generating this report. References [1] G. W. Gerrity. A Process Model for RHODOS. Technical Report CS90/7, UNSW, Australia, March [2] D. De Paoli. The Multiple Strategy Process Migration Manager for RHODOS: The Logical Design. Technical Report C93/37, Deakin University, Australia, Dec [3] A. Goscinski. Distributed Operating Systems. The Logical Design. Addison- Wesley, [4] A. Goscinski, M. Hobbs and G. Whickham. Interprocess Communication in RHODOS. Technical Report C94/, Deakin University, Australia (in preparation). 18