1. No category

Course Project: Simulating Process Synchronization in an Operating System model
Due Date: On/before August 19, 2014 (requires a group demonstration and interview for evaluation)
Before you start developing your Project:
You may consult with these external web links before you start writing your code. These links are going to help you understand
the basic facts of implementing a simulation of an Operating System model.
1. These two links has the directions of what are the tools are needed to develop an Operating System.
a. How to develop an operating system using C++? http://www.cplusplus.com/articles/zv07M4Gy/
b. What are some resources for getting started in operating system development?
http://stackoverflow.com/questions/43180/what­are­some­resources­for­getting­started­in­operating­system­development
2. http://wiki.osdev.org/Getting_Started .... This is a wiki portal for OS developers.
3. http://www.osdever.net/tutorials/ … Various tutorials are available for developing different parts and/or components of an
Operating System.
4. TRY TO USE POSIX BASED KERNEL FOR YOUR DEVELOPMENT. You will find lots of web resources for your
implementation guidance. Don’t use any Micro Kernels. You will not get any help for Mac OS based model and any
implementations will NOT be evaluated for marking.
5. DONOT NEED TO DEVELOP BOOTLOADER. You may use any open source bootloader. GRUB
(http://www.gnu.org/software/grub/) and gummiboot (http://freedesktop.org/wiki/Software/gummiboot/) are two popular one.
6. Follow the Keep It Simple Silly (KISS) paradigm. Make the model simple such a way that it fulfills all the project
requirements.
Project Overview:
Each group will design and implement a minimal model that simulates process synchronization of an operating system for a
fictional computer architecture. The simulator will execute on a Virtual Machine. The simulator must be capable of accepting
job requests, scheduling, and resource management. Final solution must be capable of accepting multiple jobs, each
competing for resources and simulates any process simulation techniques.
Requirements:
The following requirements must be completely and separately fulfilled.
Process States: You must refer to the 5­state model introduced and discussed in the textbook and lectures. Note that this
model requires queue structures and process management described in the text.
Job Descriptions: A job (or program submission) must be abstracted – actual jobs would be the binary files associated with executable
programs, together with the job header that contains the resources required to complete the job. Each job must be typified by a header. The
submission of the job consists of presenting to the O/S job submission utility a header file that will contain all required information concerning
the job. This information must include: a. Total memory length of the simulated process once it has been loaded into RAM – a paging (page­frame) model of memory
allocation and management will be used.
b. All device resources to be requested (note that the RAM request is provided above and CPU requests are automatically
assumed)
Machine Architecture: The necessary and important parts of the machine architecture that your simulator must have include a
RAM, a CPU with registers, a system clock, and input and output devices. The I/O devices must include standard input and
output devices (eg. keyboard, monitor, or disk files), and at least one user accessible disk drive; but, the addition of more I/O
devices will be a worthwhile strategy to support earning additional marks.
To be specific, you must assume a 32 bit addressing scheme, allowing for up to 4 GB of address space, though you are not
required to use that – the actual physical memory in a computer is a datum that the O/S must be aware of at bootstrap time. Assume that all registers are 32 bits in size also – they may be conveniently data typed as int or int*.
The RAM is very important to the project in that all programs, including code, data and stack portions, must be loaded into the
RAM for execution. The RAM will be subdivided into sections called pages (discussed in the textbook and lectures) of preset,
finite and short length (eg. 4KB, 8 KB, etc.) and the O/S simulator must manage how programs use paging.
You are not required to implement memory management.
A simple user interface should be developed to facilitate testing, I/O and obtaining diagnostics of the simulator behaviours.
This will make the job of testing much easier if the process is well thought out ahead.
This is a simulation of hardware, not reality! Your primary focus should be on what happens within the CPU when instructions
are executing, and in particular what happens when interrupts occur and state transitions occur.
Process and Resource tables, Queues and Management: The simulator must be aware of and manage all the hardware and
system software resources of the machine to be modelled. The simulator program itself will NOT require self­management, nor
will it require bootstrap loading and initiation ­ this is quite a simplification in itself. Resources must be mapped to various
tables that list the resources and how they are accessed. User programs, or jobs, that are submitted must also be entered into
appropriate data structures, queues of Process Control Blocks, to support the management strategy.
Each process may exist in one of several states, as discussed in lectures and the textbook, and a minimum of a 5­state
process schema must be implemented. Additional states may be added by each group and may support earning additional
marks, depending on the quality and completeness of the solution obtained (no marks for saying ‘I tried’).
You don’t need to maintain queue data structures in RAM model – consider that the RAM as entirely available for user
processes. The simulator must create and maintain a variety of variables, lists and tables. These must be used for user
processes, resource management, resource allocation, and scheduling. Lists will be required to store and maintain process
queues in various states, manage and schedule the O/S operations (including long/medium term and short term scheduling,
process dispatching, interruptions, event handling, I/O requests, exception handling, and other matters).
It is highly recommended to develop the basic code infrastructure needed to create and manage a single abstract data type
structure (ADT), and then reapply this to create similar ADT’s. In this respect, perhaps an object oriented approach is useful
(C++, Java), but a set of well­designed C functions will serve just as well.
Scheduling: All processes must be scheduled in order to support multiprogramming. In the lecture the focus was placed on
FCFS and SJF approaches, but other approaches have been dealt with in the textbook and in other courses, notably Round­
Robin (most often used with FCFS) and Priority schemes. Scheduling must take into account several factors, including the time
slice allocation to each process, the possibility of deadlock within resource sharing (where one process must wait for another
to finish, but where the other process is also held waiting for the first one to finish). Each group should implement both short
term and long term scheduling approaches. To make this project easy and simple, pre­emptive scheduling is excluded in this
project requirement.
The total elapsed time of a process, within a given time slice, can be calculated following each instruction/operation and then compared to the
allocated time permitted, with process interruption programmed to occur upon the triggering event. Note that time slices are rarely precise; rather,
if time remains in the current slice, the next instruction will be permitted to execute completely even if it causes the actual time used to exceed the
allocated slice. You should also consider process­timing overruns, which may then be dealt with using a suitable exception handling strategy that
accounts for scheduling updates. Exception handling is not required for this project simulation but any group can implement to sharpen their
programming skills.
Keep in mind that the O/S system processes are usually given a higher priority of access to resources than user processes and this should be
reflected in the approach.
User Processes Synchronization and Simulation: Since a multiprogramming operating system is intended to support the execution of multiple
user processes, in addition to the O/S processes, your simulator must be able to simulate the execution of processes. Each group will design an
approach to simulating processes.
Each process can be described by several attributes. The process attributes include: (i) total RAM allocation request (program length); (ii) PC
register (contains the relative offset from logical address 0); (iii) device requests and allocations; (iv) run time length request; (v) actual run time
length (from start to current interrupt); (vi) process state; and other attributes as necessary or desired.
You must demonstrate process synchronization by using any one of the examples described in textbook and discussed in lectures (i.e. consumer­
producer, reader­writer or dinning philosophers).
Be creative and innovative when you are developing your own test suite of pseudo­processes.
User Interface and Reporting: A simple user interface should be developed to facilitate testing, I/O and obtaining diagnostics of the simulator
behaviours. This will make the job of testing much easier if the process is well thought out ahead. Such interfaces should be kept as simple and straightforward as possible – hence, command line text interfaces are expected, but developing a
more sophisticated GUI is also possible and will be considered for extra marks within this requirement category. Students are warned that a great
deal of programming effort may be required to implement even a simple GUI, so this should be considered very carefully before committing time
and effort to this when other more vital requirements have not yet been fully satisfied.
You must be able to show what the lifetime of a process is from submission to termination – this can be logged very simply and read later in an
editor. You should be aware of what the resource management status is and what the current schedule is. Reporting on CPU utilization and I/O
utilization is recommended. Finally, but not the last word on the subject, you should generate comparative statistics on total run time for a gang
of jobs using two different scheduling approaches, one of them being the SJF algorithm. Let the simulation model you design speak to you and
help you to understand and appreciate the complexity of such systems and also the behaviours of different underlying algorithms.
Where groups demonstrate the ability to run simulations, gather data, then analyze and portray the data in straightforward graphs, showing the
effects of modifying parameters on performance, throughput, wait times, and so on – for many useful operational measures – such groups will
have demonstrated a very high level of excellence.
Project Demonstration and Evaluation: Each group must present the complete project with all, or most, project requirements fulfilled. For each project, in addition to the group demonstration, there is also a required submission; each group must submit (1) a single report
document – it may be a straight ASCII file, or a Word document, or a PDF document, and (2) all source codes for their project program. The
report document will consist of a title page listing the course, the project component title and the names and email addresses of all group
members (it is NOT necessary, NOR recommended, to include Student ID numbers in the interest of individual security). It is recommended
that all features of the component code be listed – this is a useful checklist to determine if the requirements have been met. The GA may use this
document to verify the achievements listed, as well to ask additional questions of understanding from each member of the group.
Project Team:
Each team must consist of 2 to 4. Each team must submit a list of the names of each group member to your instructor (Mr Subhani) by email –
this email MUST be CC’ed to all group members so that correct email addresses can be determined and verified, and so that all members of each
group are kept fully informed of such communications. It is essential that the full group meet as soon as possible to establish the group’s level of
understanding and to begin the process of asking clarifying questions of the instructor. All members of the group must be fully involved in all
aspects, from design to coding to testing. Use each other to bounce ideas off and to troubleshoot when problems arise.
Evaluation: Each requirement must be met in order to obtain marks. To determine whether a requirement has been met, the program will be subjected to a
variety of tests. All source codes should be documented in order to support possible awarding of partial marks.
The table below provides the scheme and weights that will be used for evaluation:
Title
Weight
Requirements Description
Part I
5­State Process Model
5
Job Submission
5
 The 5­state process model described in textbook and lectures
in the base of this project. More complicated model may be designed
and implemented by adding or extending the 5­state model.
 Job submission header file
Part II
Machine Architecture
 RAM model for user processes
5
Process and Resource tables;
Queues and Management
 CPU functionality
 I/O devices
 You may design your own system clock functionality
 Resource management tables
20
 Device management tables
 A 5­state queueing model
 Queue management
Part III
Scheduling
 Short term and Long term
30
 Round­Robin, FCFS, SJF, Priority
 Deadlock avoidance/prevention may be implemented
Part IV
User Processes Synchronization
and Simulation
 Simulation of single process execution
25
 Multiprogramming support and management
 Synchronization and Critical Sections
 Peterson Solution to critical sections
User Interface and Reporting
 Command line interface
10
Project Demonstration and
Evaluation
100
 Reporting summary statistics gathered during simulation run
 Comparative statistics for various scheduling using two or
more different algorithms
 All requirements listed above.
Submission Requirements:
All project submissions (for the entire project) MUST be emailed to the course GA Mr Shaochen Zheng
([email protected]) by each group. This email will establish the submission date and time (according to the
email date/time stamp).
All project submissions MUST be presented to the course GA by each group – the presentation must be set up by appointment
with the GA. All late components will have the prescribed penalty assigned immediately, depending on how late it is sent
(according to the email date/time stamp). The evaluation MUST be performed using the identical software version sent by
email.
Read and discuss ALL parts of this project description before proceeding with the work. Do not hesitate to ask questions (in
class, by email) to ensure you do understand fully what is required of you.
Be FOCUSED and be CREATIVE. Don’t just write SPAGHETTI code.
Good LUCK on good Programming!