---

Synchronization in IO communciation, Part I: Releasing the CPU

---

• We need to decribe some aspects of the Operating System in order to understand what happens when a program performs an IO operation and making itself unable to continue with its execution.

• Every computer nowadays is controlled by a huge program called an operating system or OS for short.

  The OS manages all the resources in the computer system.

  Some common examples of available operating systems are:

  • Microsoft windows (for PCs)
  • Linux (a UNIX operating system for PCs)
  • Solaris (the UNIX operating system for Sun Micro workstations & servers)
  • MAC-OS (the operating system for MACs)
  • etc. etc.

• The OS is huge and manages every aspect of the computer system.

  A good OS will always try to make the computer system run as efficiently as possible, meaning: do not waste any resource unless it is absolutely necessary.

  I will only expose that part of the OS that is relevant for managing IO communication so that the CPU (a resource managed by the OS) is not wasted when a program cannot continue with its execution.

• At any one time in the computer system, there will be many different programs inside the computer that can be run if they are given control of the CPU.

  The different programs are stored at different locations in the computer memory.

  The phrase "give control of the CPU to program X" means that the CPU will fetch and execute instructions pertaining to the program X.

  (If you know how the CPU works, you should immediately conclude that the above sentence means that the program counter contains an address value that is in the range of the address locations occupied by program X).

• In order to manage the different programs, the OS (which itself is a program, and programs have variables !) maintain various queues (a queue is a linked list which is a special kind of variable - this is CS253 stuff).

• For our discussion in synchronization for IO communication, the following queues are relevant:

  

  • Ready Queue: is a linked list of PCBs of programs that are ready to run

    The PCB at the head of the Ready Queue always pertains to the program that is currently executing (i.e., the CPU is fetching and executing instructions from that program).

  • Various device queues: linked lists of PCBs of programs that are waiting for IO operations to complete - these programs are not ready to run.

  ---

  ---

  ---

  ---

• There are some terminologies in the above description that need clarification:
  • PCB is the acronym for Process Control Block.

    A "process" is a program that is being executed by the computer

    It is important to know the difference between a "process" and a "program".

    A program consists of computer instructions, A process consists of something more than just computer instructions in a program: it also include the current state (values of variables and registers, including the next program address in the PC (program counter))

    The process state consists of all the information other than the program itself that is necessary to continue running the program if the program is halted at a particular point.

    In other words: suppose you pull the plug on the computer that is running a program (say some video game). The process state is all the information that is necessary to allow you to restart the computer and continue with that program from the moment when you pull the plug.

    Context:

    The process state is also known as the context of the process contain inside the CPU.

    The context infomation consists of the following information in the CPU:

    Content of all the (general purpose) registers Content of the program counter Content of the processor status register (PSR - containing the flags and other processor status information)

    In other words:

    If you save all the content of the registers, the program counter and the processor status register of the computer that is running a program X right now, (and assuming that you still have a copy of the program X), and pull the plug on the computer, then you can restart the computer after an hour, or a day or even a year from right now, and the program will be able to continue from the point when you saved the process state. (The content of the registers, PC and PSR can be saved on disk if would pull the plug on the computer, but in the discussion of IO communication, we will not cut the power off and we can save the registers, PC and PSR in the memory of the computer system).

    Saving context and restoring context:

    The act of saving the content of the registers, PC and PSR is known as saving the context The act of putting the saved values of the registers, PC and PSR back into the register, PC and PSR is known as restoring the context. (Afterall, the context (process state) consists of the content of the registers, PC and PSR.)

    BTW, in class, I often use the term "freeze a process" to mean "saving the context of the process" - I got that from some science fiction story which proposed to have humans who are suffering from currently incurable deseases to be frozen until the time that we have develop a cure for such deseases and at which time to "unfreeze" the bodies to be treated (don't ask me which science fiction book it was, too long ago...)

  ---

  ---

  ---

  ---

• Ready process
  • The term ready has a very precise meaning in operating system.

    A process is ready if the program can continue its execution (from a state in which the context was saved) without resulting in execution errors.

    In our discussion, a process is ready if it is not performing an IO operation.

    (Because if the process is performing an IO operation - such as reading data from disk - then the data is not ready yet and it you allow such program to continue, the execution will not compute the correct value (based on the principle of GIGO - garbage in, garbage out - wrong data in, wrong data out).

  ---

  ---

  ---

  ---

• Now we can explain what will happen when a program (it is actually a process) performs an IO operation:

  A IO operation (such as read(...) will call a subroutine inside the Operating System: (For simplicity, I am using M68000 registers A0, D0 and D1 to pass the parameters... Technically, the parameters are passed on the stack)

  • You can see that P1 is at the head of the ReadyQ, so program P1 is currently executing (CPU fetches and executes instructions from program P1.

    Therefore, (because instructions modify registers), the current content of the registers, the PC and PSR are process state of program P1.

  • Program P1 will perform an IO operation next. Typically, the programmer will write a statement like:

        read(buffer, inputfile, numberOfBytes);
      

    in a high level programming language which will be translated into the following assembler instructions:

    move.l #buffer D0 // Pass parameters move.l inputfile, D1 move.l numberOfBytes, D2 jsr OS_Read // Call subroutine in OS to // to handle the read IO transfer

  • The subroutine OS_Read is one of the many service routines that program languages can use to perform system dependent functions.

    There exists many different kinds of service routines, ranging from routines to set the clock in the computer to aborting a program (the "kill" command in UNIX invokes such a service routine).

    The service routines are called system calls (in UNIX) or supervisory calls by IBM.

    A service routine is a program (subroutine) that performs a specific function.

    In our example, the OS_Read service routine must perform a read operation on behave of the requesting program (P1). The OS_Read routine will looks like this:

    OS_Read: (Uses D1 to tell the DMA to go to a particular part of the disk that contains the data for the specific input file) move.l D0, 2012 // Program Address register of DMA move.l D2, 2016 // Program Count register of DMA move.l #1, 2004 // Assumed: command code for IO write ..... (to be continued) <--------- point A

    We have seen these assembler instruction before (see click here). Recall that we have assumed that:

    • Memory-mapped IO
    • Status register: at address 2000
    • Command register: at address 2004
    • Data register: at address 2008
    • Address registerat : address 2012
    • Count register: at address 2016

  • Recall that at "point A" in the above program, the DMA has been started to perform the IO operation on behave of program P1 (the currently running program) and that program P1 cannot proceed (because the data is not ready yet).

    Therefore, program P1 is no longer ready.

    Therefore, the OS must stop program P1, but:

    the OS must stop it in such a way that program P1 can be restarted at a later time !!!

    From the previous discussion, you would conclude that you need to:

    save the context of the current process (context = the value stored in the registers, PC, Stack Pointer and PSR) !!!

    (PC = program counter, PSR = processor status register)

    The place where you want to save the context information is the PCB pertaining to the program P1:

    The PCB of the current running program (= process) is always at the head of the read queue

    After saving P1's context, you must remove the PCB from the Ready Queue (because P1 is not ready and the Ready Queue only contains PCBs of processes that are ready).

    The PCB must be entered into the device queue of the device that is servicing the IO request. The reason for this will be clear in part 2 where we discuss a technique to reclaim the CPU when the IO operation is finish.

    Finally, a new ready program is started by restoring the context from a PCB structure in the Ready Queue.

  • The following is the complete "psuedo code" for the OS_Read service routine:

    OS_Read: (I will use psuedo code here because assembler code will be very tedious - I rely heavily on your knowledge of linked lists from CS170 and/or CS253) 1. Save the context into the first element of the ReadyQ 2. Program the DMA to perfrom the IO operation (Uses D1 to tell the DMA to go to a particular part of the disk that contains the data for the specific input file) move.l D0, 2012 move.l D2, 2016 move.l #1, 2004 ) 3. Remove the first element of the ReadyQ and insert it into the DMA queue 4. Restore the context using the values in the (new) first element of the ReadyQ (Note that this first element is actually the second element in the "old" ReadyQ because the first element has been removed in step 3.

  • The following picture shows the situation after the OS_Read service routine finishes:

    

    Notice that:

    • Program P3 is now running - so that the expensive CPU resource is not wasted
    • Program P1 is suspended and we know where to find it: in the DMA queue. This will be the key to the reclaim the CPU back step when the DMA finishes the IO operation.

  • The net effect of a read() IO operation operation with respect of the CPU is:

    The context in the CPU belonging to the "previous current program" was saved its appropriate PCB The context in the PCB of a new current program was loaded into the CPU.

  • The net effect with respect to the CPU is there is a "switch" (= change) of context information.

  • That's why this operation is called context switching:

    Context switching = save the context of the current running process and load the context of some other (stopped) process