3 Case Studies of SCOOP
3.2 Electronic Workbench (EWB) Stated Process
Usually an operating system process switches states when the operating system transfers the control of execution from one process to another process. Switching of process states is required so that a process cannot monopolize the processor. Due to this requirement to switch among states, the usual process object can be better represented by a stated process object because the stated object inherently maintains the states and transitions of the object. Representing a process by a stated process object also helps to reduce the responsibility of the operating system to track the data structures used for keeping the state information of the process. This is because the stated process object keeps track of its state information by default. According to one of the adopted standards [8], a process typically realizes seven states. These well-defined seven process states, given in the table below, can be used as the seven states of the stated process object.
Table 3.2 ‘Process’ Stated Object States, from [8]
In the process state diagram, Figure 3.2, from [8], a transition arc from each state to the exit
state is implicit but not shown for clarity. However, it is possible that from any state the States Description
New A process that has just been created but has not yet been admitted to the pool of executable processes by the operating system.
ready A process is in main memory and is prepared to execute when given the opportunity.
ready/suspend A process is in secondary memory but is available for execution as soon as it is loaded into main memory.
running A process that is currently being executed.
blocked/suspend A process is in secondary memory and awaiting an event.
blocked A process is in main memory and awaiting an event to occur.
Exit A process that has been released from the pool of executable processes, either because it halted or because it aborted for some reason.
21
process can be transitioned to the exit state either because the user decides to close the process or the operating system forces the process to exit.
Figure 3.2 ‘Process’ Stated Object Model, from [8]
Let us assume that the operating system receives a user request to initiate an Electronic Workbench (EWB) software application. The operating system creates the EWB stated process object, in the new state, so that it can load the EWB application in the EWB process space. The EWB application is supposed to be loaded in a single thread. Immediately after creating the stated process object, the operating system invokes the ‘admit’ function that transitions the EWB process object to the ready state and the EWB application is loaded in the EWB process space in main memory. If the operating system is already running enough processes, the EWB stated process is kept in the ready state for a period of time and the user has to wait. After waiting, the operating system invokes the ‘dispatch’ function to transition the EWB process to the running state and the EWB application starts execution. The EWB application is now running and the user can interact and use the EWB application as long as its EWB process is in the running state.
When the user requests the EWB application to open an existing workbench file, the EWB switches to ‘file_open’ mode to wait for the user to select and issue the ‘open’ command for the selected file. Now the operating system realizes that the EWB application has to wait for an event to occur. Therefore, the operating system transitions the EWB process to its blocked
22
operating system catches the ‘file_open’ event along with the selected file name. Furthermore, the operating system issues the ‘event_occurred’ command to transition the EWB process object from its blocked state to the ready state. If there is no other ready process in the ready state queue then operating system can transition the EWB process object to the running state immediately and the EWB application can proceed to load the selected file to open in the EWB application.
If the EWB process is in the running state then the user can use the EWB application. If the user selects the ‘close’ command for the EWB application, then the operating system transitions the EWB process to the exit state and the EWB application is unloaded from main memory, i.e. the EWB application is unloaded from the EWB process space. Since the screen handle is not readily available, the redraw thread is transitioned to its transition state and the EWB process stays in its blocked state. As soon as the screen handle is released by the other process, the operating system triggers the ‘screen_available’ event to the EWB process while passing along the screen handle. Now the EWB window transitions to its ready state, triggers the ‘resource_ available’ event to the redraw thread that transitions the redraw thread to its
ready state. According to the scheduling of the operating system, the redraw thread is transitioned to its standby state where it is eventually switched back to its running state and continues the screen redraw operation from where it was suspended.