CSCE 311
Spring 2003
Project #3
Assigned: Monday, March 17, 2003
Due: Wednesday, April 2, 2003 (2:30pm)
Objective
The objective of this assignment is to implement interrupt handling for the OSP simulator. Module INTER will be used to implement general interrupt handling. Module PROCSVC will be used to implement process management monitor calls.
Required to turn in:
· Follow all directions. You will lose points for not following hand-in procedures. Late assignments are unacceptable and will not be graded.
· You must turn in hard copies of the files inter.c and procsvc.c. You must document all code sufficiently; this is a significant portion of your grade.
· You must turn in a hard copy of one run (i.e., simulation.run). The run must be produced by using the parameter file provided and the '-d' option of the simulator.
· You must also submit a one-page description of what you hand in; this must contain explanations of how you solved the problem with a focus on the use and manipulation of data structures. If you did not manage to finish the assignment, your description should say what you did manage to do, what you were unable to do, and why you could not complete the assignment.
· An electronic submission of your solution (inter.c and procsvc.c) is required. You must submit this electronically using the dropbox (not Blackboard), and you can submit several times up until the due date.
Building and executing the simulation
To get the definition of NULL, include the header file stdlib.h. This and any other changes to the files inter.c and procsvc.c must be done under the "Internal Routines" section of the files.
Copy the files below into your directory:
~osp/project_3_002.sun4/Makefile
~osp/project_3_002.sun4/OSP.demo
~osp/project_3_002.sun4/inter.c
~osp/project_3_002.sun4/procsvc.c
~osp/project_3_002.sun4/dialog.c
~osp/project_3_002.sun4/simulation.parms
You should only have to modify inter.c and procsvc.c. You can modify dialog.c if you wish, but it is not necessary. OSP.demo is a compiled executable for you to use in comparisons with your program: The file Makefile is for use with make. Compile and link your program with the make command:
> make
This creates an executable called OSP. Run your program with the following command:
> ./OSP simulation.parms
The output goes into a file called simulation.run. Successful runs produce an output to the screen containing a 'FINITA' or something similar. To run your program with the '-d' option for submission:
> ./OSP -d simulation.parms
It is recommended that you test your program with more than one set of simulation parameters. All commands must be executed in the same directory as you copied the files to.
Overview of interrupt handling in OSP
OSP uses several modules to implement interrupt handling. Interrupts are supported by the Int_Vector data structure in OSP. To cause an interrupt, a routine sets the contents of Int_Vector and calls the general interrupt handler [gen_int_handler()]. The cause field of Int_Vector is always set to indicate the type of interrupt that is occurring, while the other fields are set depending on the type of interrupt. This is the method used by other modules implemented in this class when interrupts need to happen. In a real system, this process is done in hardware. The OSP manual has a description on interrupt handling in OSP.
General interrupt handling
The general interrupt handler in module inter.c does several things:
• When gen_int_handler() is first entered, the just-completed CPU burst of the interrupted process and its accumulated CPU time should be updated.
• Just before exiting gen_int_handler(), a new process will have to be scheduled by calling dispatch() in module cpu.c.
• In OSP, interrupts can cause other interrupts--interrupts can become nested. Only the outermost invocation of gen_int_handler() should update the interrupted process's accounting information and dispatch a new process or else the interrupted process's information will be updated multiple times and the process will be rescheduled multiple times. In order to do this, gen_int_handler() should keep track of how many times it has been entered (in C, the use of a static variable is necessary).
• The body of this handler calls the appropriate special purpose handler based on the cause field of Int_Vector and passes the appropriate parameters.
The OSP manual provides details on what the module's functions should do and relevant data structures.
Process management monitor calls
There are five process control interrupts: sigsvc, waitsvc, killsvc, termsvc, and startsvc. These are handled in the module procsvc.c.
• The sigsvc and waitsvc monitor calls provide an event-based facility for process synchronization and correspond to signal_handler() and wait_handler() respectively. Any number of processes can wait on a single event. Signaling an event awakens all processes waiting on that event. Events are represented by EVENT structures, each of which has a pointer to a queue of processes waiting on that particular event. This pointer is initialized by OSP to be NULL when the simulator creates the EVENT structure.
• The termsvc and killsvc monitor calls are generated when a process is terminated normally or abnormally (by being killed) and correspond to term_handler() and kill_handler() respectively. These calls release resources held by the process that is terminating or being killed by making calls to other modules external to procsvc.c.
• The startsvc interrupt is generated when a new process arrives in the system and corresponds to start_handler().
The OSP manual has more details on what these functions are supposed to do and relevant data structures.
Some hints
• Do not wait until the last minute to get help or start working on the assignment.
• Read the OSP manual for full descriptions of what the modules' functions do and what data structures and external routines they use. A description of the Int_Vector structure and interrupt types is on page 5. Information on interrupt handling in general is on pages 12-16. Information on process management calls in on pages 17-20.
• Since the general interrupt handler is used to call the special purpose handlers, it makes sense to implement the general interrupt handler first. Build up to a solution in stages. Trying to implement everything at once will be difficult if there are errors to debug.
• Modifying dialog.c is not necessary, but may be helpful if you want the simulator to print out additional information during errors, warnings, or snapshots for debugging purposes.
• In the case of core dumps or other fatal errors, you may want to run interactive simulations and/or use the trace switch in the parameters file to see what happens before the dump. A debugger (such as gdb) can be used to examine core files and generally assist in debugging.
• The trace switch in the parameters file is also useful when you want to see details of what happens inside the simulation when you get warnings or errors.
• Pay attention to what the simulator tells you is going wrong. However, not every error or warning the simulator reports will be directly traceable--your modules’ incorrect actions may lead to errors in other modules. As in normal debugging, pay particular attention to the first few errors reported.
• Performance is not a consideration in grading. Getting it working is the only goal.