---

Synchronization in IO communciation, Part 2: Reclaiming the CPU

---

• Thus far, we have seen that:
  • When program P1 performs an IO operation that causes the program to become not ready, the OS stops the program by saving its context in the corresponding PCB structure variable, removes the program from the Ready Queue, puts it in the DMA device queue and then resume with another ready program

• The program P1 that has requested an IO transfer operation will remain not ready as long as the IO transfer is not completed.

  But as soon as the DMA has completed the IO transfer operation, the program P1 is again ready (because it can then continue with its execution without causing any errors).

  Therefore, as soon as the DMA has completed the IO transfer operation, the PCB of program P1 (which can be found in the DMA queue), must be removed from the DMA queue and insert back into the Ready Queue (so that it can (re)claim the use of the CPU).

• The question is how can the CPU tell if the DMA is done with the transfer operation....

  Well, one simple solution is to have the CPU read the status register of the DMA from time to time to see if the DMA has become idle.

  But this apporach is inferior to the commonly used solution that uses interrupt signals

• An interrupt is a special signal on the control bus that is used by IO devices (DMA) to request the attention of the CPU:

  

• The instruction execution cycle (see CS255 class note: click here) has in fact one more phase !

  The complete instruction execution cycle is as follows:

  Fetch (assembler) instruction from memory at address PC and increment PC (to point to the next instruction) Decode instruction fetched. Fetch operands needed to execute the instruction Execute the instruction Check for interrupt signal(s)

• When the CPU detects that the interrupt signal is raised (i.e., some IO device is sending an interrupt request), then the CPU will make a (unprogrammed) subroutine call to a location in memory given by a special Interrupt Base Register (IBR).

• I will first present a simplified version of how the CPU processes an interrupt signal (because giving the full details of the operation of vector interrupts may make you miss the main issue at hand):
  • I will assume that there is only one IO device (controled by 1 DMA).

  • The Interrupt Base Register IBR contains the starting of a routine and from the description above, the CPU will make a (unprogrammed) subroutine call to this routine when the DMA raises the interrupt.

  ---

• A subroutine that is called (= run) in response to an interrupt signal is called a interrupt handler

  ---

  ---

• To give you an idea what it "feels" like to have a program make "unprogrammed subroutine calls", I have created the following C program that prints "." repeatedly in a while loop:

  /home/cs355001/demo/interrupt/interrupt.c gcc /interrupt.c a.out

  The main program loop looks like this:

  while (1) { for (i = 0; i < 999999; i++); // Slows the program down a bit... putchar('.'); // Print "." fflush(stdout); // Make sure the character is displayed }

  If you run the program, it will print:

  .................................................
  .................................................
  .................................................
  .................................................
  

  and so on....

  You can force this program to make a "unprogrammed" function call to the function Int_Handler by typing Control-Z !!!

  It will print the text:

    !!!!!! Hello !!!!!!!!   
  

  and then return to the while loop and continue to print ".". You can force it to call Int_Handler over and over again, but typing Control-Z.

  ---

  ---

• Example Interrupt Setup in Assembler: (Demo above code)                                                

  /home/cs355001/demo/interrupt/interrupt-io.s as255 interrupt-io m68000

  How to run the program:

  use m68000 There is an infinite loop in the code Technically, the program will never go somewhere else But it does jump to intClkHandler after a number of steps !!!

  ---

  ---

  ---

  ---

• Let us get back to the IO communication problem, part II: how to reclaim the CPU when the IO operation finishes.

  Recall the situation prior to the completion of the IO operation:

  

  Make sure you understand what you want to achieve:

  The IO transfer initialized by Program P1 has completed. So program P1 has become ready We need to move program P1's PCB (process control block) back to the Ready Queue so program P1 can continue its execution (by making the CPU execute instructions of program P1)

  ---

  ---

• We achieve this as follows:

  Write a routine that moves the PCB from the DMA queue back to the Ready Queue      and Arrange to have the CPU execute this routine using the "unprogrammed" subroutine call mechanism. This mechanism is interrupt -- so we make the DMA raise an interrupt signal when the DMA is done !!!

  Recall that in the (simplified) interrupt handling, the CPU will make an "unprogrammed" subroutine call to the memory location given by the IBR (Interrupt Base Register) when the CPU detects an interrupt signal.

  The following picture depicts the "reclaim the CPU" solution:

  

  While program P3 was running on the CPU (i.e., CPU fetches and executes instructions from program P3), the DMA completes the data transfer operation. When the DMA finishes the IO transfer, it will raise the interrupt signal. The sequence of events that follows is:

  • CPU finishes executing an instruction from program P3

  • CPU detects the interrupt signal, as a result, makes an subroutine call to the address given by IBR (in this example, IBR = 17000, so CPU runs the subroutine at 17000)

  • The subroutine at 170000 is given in the figure.

    This subroutine will contain program instructions that instruct the CPU to do the following (in pseudo code):

    CPU sends out the INTA (Interrupt Acknowledge) signal - there is an assembler instruction "IA" that instruct the CPU to do this (not covered in CS255 because there was no need to then). In response to the INTA signal, the interrupting device will lower its interrupt signal (because it knows the CPU is handling the request). Save the context information from the CPU (register, PC and PSR) into the PCB at the head of the ready queue. Recall that the head element in the Ready Queue is the PCB data structure used to store the context of the currently running program This step will save all the information that the currently running program needs to be restarted later I.e.: this step prepares the currently running program to be stopped !!! Move the PCB from the DMA queue back into the ready queue (the PCB pertains to the program that requested the DMA IO operation. Now that the DMA is finished, the program has started an IO operation has become ready. This program is ready to run. So it is only proper to move the PCB back to the ready queue where it now belongs. Usually, the PCB from the DMA queue is inserted at the head of the ready queue. In this case, the PCB of program P1 will be at the head of ready queue after this step This also means that P1 will be run next !!! Finally: restore the context from the head of the ready queue. Because the PCB of program P1 is at the head of the ready queue, the CPU registers (in particular the Program Counter PC) will be loaded with the values that belong to the program P1... Because program counter PC points to an instruction inside program P1, the program P1 will be resumed (because the CPU is fecthing instructions from P1 !).

  Therefore, program P1 has reclaimed the use of the CPU - exactly when the DMA finishes the IO operation on behave of program P1.