FINAL MPX DELIVERABLE Due when you schedule your interview and presentation

KEY CONCEPTS The main goal of this module is to integrate R5 with your command handlers. You will also do the following: 1.Implement continuous dispatching of processes 2.Implement I/O scheduling which will allow multiple processes to post I/O requests to the same device. 3.Test your total program with a printer and remote terminal connected to a test computer.

Continuous Dispatching of Processes In previous modules, the MPX spent the majority of its time executing the command handler which was not a process. In a true multitasking environment almost all programs including command interfaces are considered processes. Your final MPX must allow the user to initiate many processes and keep them executing even as the command handler is running

Continuous Dispatching of Processes The command handler was used to load and dispatch a certain number of processes. The command handler then resumed control when execution of the processes was done. In the final MPX module two processes will be competing for computer resources

Continuous Dispatching of Processes COMHAN – Comhan will be created as a system process, and should be assigned the highest possible priority. IDLE PROCESS – (supplied in your MPX support routines) IDLE will be a low priority process which the dispatcher will execute if all other processes are blocked awaiting I/O. It will be created as a system process and must be assigned the lowest possible priority.

Continuous Dispatching of Processes Each process (including the comhan) executes until it performs a system request or until an interrupt occurs. System requests or interrupts may cause a new process to be scheduled by a context switch. All requests for keyboard input or terminal (screen) output are intercepted and handled by MPX. All keyboard input must be captured by performing a sys_req (READ) operation to the device “TERMINAL”.

Continuous Dispatching of Processes The test processes vary in function: All processes except the IDLE process will produce regular output. Some are CPU bound this means that they will compute for a long time before producing output Others are I/O bound and generate messages continuously Some processes will run for a fixed number of repetitions, while others run indefinitely until manually terminated. One process besides the command handler accepts input.

I/O Scheduler In this module you will implement I/O scheduling which will allow multiple processes to post I/O requests to the same device. If a device is available, a request is scheduled immediately, otherwise it must be placed in a queue, and preserved until the requested device becomes available. Processes making I/O requests must be “blocked” until their I/O request completes

The I/O Scheduler Purpose of the I/O scheduler: 1.Maintain a queue of pending I/O requests, one for each device. 2.When a device becomes available, it will select a pending request, copy information into the IOCB for the device, and initiate the request 3.Monitor the status of ongoing I/O requests for error or completion via an interrupt handler.

General structure and organization The main elements of the final MPX system are: Main program Command handler Processing routines for each command Dispatcher and system call handler Device drivers : PRINTER, COM_PORT, TERMINAL (a terminal driver is supplied in the support routines) I/O scheduler I/O completion handler System data structures Storage area for the loaded processes.

Initialization Steps of initialization of your MPX sys_init(MODULE_F +...) /sys_set_vec(sys_call) open device drivers initialize DCBs and waiting queues initialize PCBs and ready queue install command handler as a process load IDLE and setup a process Install the Idle process call dispatcher sys_exit() close device drivers

Initialization Initialization of the MPX is performed by the “main” function sys_init(MODULE_F +...) - perform system initialization for MPX sys_set_vec(sys_call) - set the system call handler to your routine open device drivers - for each of your device handlers, call the “open” function initialize DCBs and waiting queues – perform any needed initialization of data structures maintained by your device drivers, I/O schedulers

Initialization initialize PCBs and ready queue - Create and initialize a PCB for your comhan. This PCB should be initialized in the same manner as the PCB for the directly linked processes of module R3. Its initial execution address must be set to the entry point of the COMHAN procedure. The stack size for the comhan needs to be at least 4K bytes in size.

Initialization install command handler as a process - add the comhan process to the ready queue load IDLE and setup a process - Create and initialize a PCB for the idle process. This should be done by loading an executable file IDLE.MPX. It should be loaded into a suitably allocated memory area using the strategy developed in the load program command of R4

Initialization Install the Idle process - insert the idle process into the ready queue other initialization as needed call dispatcher – the first call to the dispatcher should dispatch the comhan. close device drivers other cleanup as needed sys_exit()

Termination Termination of MPX occurs when a “quit” command is issued to the comhan Outline: display opening message while not done display prompt read command analyze command execute command end while display closing message terminate all processes

Termination The last step of the comhan is to TERMINATE all processes remaining in the ready queue, freeing their associated space. This includes the process for the idle process

I/O Scheduler Revisited A typical data transfer operation begins with a request such as a READ OR WRITE issued from within the code of an application process. This request specified the transfer of a block of data from a program buffer to a device or vice versa. These requests are made via the MPX support routine sys_req Sys_req invokes the system call handler of your MPX… Until now your system call handler only processed IDLE and TERMINATE operations. We now must add code to the system call handler to intercept and interpret READ and WRITE operations

I/O Scheduler Revisited The system call handler for the Final MPX should have the same structure as in previous modules but expanded functionality. It must now handle READ and WRITE operations in addition to IDLE and TERMINATE. These operations will be passed to the system call handler by sys_req.

I/O Scheduler Revisited Each time it is invoked, before calling the specific service routines, the system call handler should perform two additional functions: 1.Call the procedure trm_getc. This procedure transfers pending keyboard characters from the MS-DOS buffer to the MPX buffer. 2.Determine if any event flags are set, and perform the required IO completion sequences.

I/O Scheduler Revisited Each I/O system request should be passed in turn by the system call handler to the I/O Scheduler. The request parameters (which are still on the stack) include, the device Id, operation code, buffer address, and address of the count variable, and the identity of the calling process (the calling process is the current running process), must be provided to the I/O Scheduler. The Scheduler should check the validity of the parameters, and return an error code if the request is invalid.

Scheduling I/O When the I/O scheduler receives a request: 1.It checks the validity of the input parameters, insuring that all necessary information is supplied. 2.It checks the IOCB of the requested device. It if it available, the request information is copied into the IOCB, and the appropriate device driver routine (read or write) is called to initiate the transfer. The PCB is placed in the blocked queue 3.If the device is busy, the request information is saved in an I/O request structure, the structure is added to the devices request queue, and the process is switched to the blocked state: 4.Execution returns the system call handler, which invokes the dispatcher to schedule another process.

Devicd ID: (“printer”, “com_port”, “terminal”) Status: “busy” ”available” Operation code: Event flag: PCB Pointer IOCB PCB pointer Device ID Operation code Buffer Address “count” address PCB pointer Device ID Operation code Buffer Address “count” address I/O request queue WE will have one IOCB for EACH device Scheduling I/O

Completion of I/O When an I/O transfer is complete, the event flag will be set in the devices IOCB (which also sets the processes event flag). For each device whose operation is complete: 1.The appropriate I/O completion routine should be invoked. 2.The process should be switched from the blocked to the ready queue 3.The fields in the IOCB should be reset. This should be performed by your I/O scheduler

Support software Test processes - A collection of test processes is provided for MPX in the form of executable program files. Each file is provided in the support package with a name extension of.MPX; these are actually.EXE files similar to those loaded in Module R4 These programs have been written in assembly language (using Borland's Turbo Assembler) to avoid the sizable run-time framework which is attached to all programs generated using Turbo C (this would amount to as much as 10K bytes per process).

Support software 12 test processes are supplied. If you have access to an assembler you may prepare additional test processes following a similar model. The supplied processes are: IDLE. The process which is used to ensure that the ready queue is never empty, and that the system always has some process to execute. IDLE does nothing but wait in a simple loop until an interrupt occurs. CPUTERM. A process which repeatedly displays a message line on the display screen. This process is CPU bound; it waits for a while in a loop between messages, consuming processor time. It runs continuously until terminated.

Support software CPUPRINT. Similar to CPUTERM, but this process prints its messages on the printer. CPUCOM. Similar to CPUTERM, but this process outputs its messages to the communication port. We assume that a standard terminal, or a separate PC or workstation running terminal emulation software, is connected to this port. IOTERM. Similar to CPUTERM, but this process includes no delay loop. It attempts to continuously output messages, making a new request as soon as the last one has been completed.

Support software IOPRINT. Similar to IOTERM, but this process prints its messages on the printer. IOCOM. Similar to IOTERM, but this process outputs its messages to the communications port. IOTRM25. Similar to IOTERM; however, this process displays its message exactly 25 times, then requests termination. A special message is displayed before the termination request. If the process is dispatched after its termination request, an error message is displayed, and the process restarts. IOPRT25. Similar to IOTRM25, but this process outputs all of its messages to the printer port. IOCOM25. Similar to IOTRM25, but this process outputs all of its messages to the serial port.

Support software IOMULTI. This is the most ambitious process. It is the only process that requests input besides the command handler, and it is the only process that accesses more than one device. IOMULTI executes a continuous loop in which it first outputs a prompt message to the communication port. It then waits for input from the remote terminal; this input should be a single line terminated by ENTER. When a line has been received, the process prints that line on the printer. The entire cycle repeats indefinitely.

Support software Terminal Driver - This driver supplies a set of routines to invoke terminal (screen) output and terminal (keyboard) input, analogous to the routines in the printer driver and serial port driver int trm_open (int far *eflag_p); int trm_close(void); int trm_read(char far *buf_p, int far *length_p); int trm_write(char far *buf_p, int far *length_p); void trm_getc(void);

Support software void trm_getc(void) - Keyboard input is acquired via interrupts and stored in a ring buffer. The trm_getc function echoes stored characters and transfers them to the requestor's buffer. This function should be called by the I/O Scheduler just before it calls the dispatcher, if terminal input is active. It is not harmful to call this routine when it is not needed, but of course it is inefficient

Testing strategy Load a process for comhan and Idle. Dispatch comhan, and ensure that your it is operating properly, testing all possible commands (without actually loading and dispatching processes) Try to load and resume one process that performs I/O to each of the different devices, one at a time. You will be required to “load” the processes, resume them and then manually terminate them. Then progress to loading multiple processes, one type at a time. Loading and running as many processes as possible. The last process that should be loaded and tested is IO/MULTI