CS 415 Operating Systems Practicum

The practical aspects of operating systems are studied by examining the tradeoffs chosen by existing systems and engineering the design and implementation of various operating system abstractions, such as threads, files, and sockets. The C language is used for all programming.

Requisites

You must be currently taking CS 414.

You must be willing to learn C if you are not already familiar with it. We will briefly review features such as structures, pointers, and memory allocation in the first class, but thereafter it will be assumed that you understand the features and usage of this language.

Projects Overview

The projects will be focused on the programming abstractions used in operating systems; the projects will require thinking about the tradeoffs to be made in implementing these constructs, as well as understanding in detail how the abstractions are used. To a lesser degree, the projects will encourage good design and programming skills such encapsulating implementation behind interfaces, ensuring robustness in systems code by always validating outside data, and avoiding leaks and other memory errors. All errors should be gracefully handled.

For projects you will typically be given an API defined by a .h file, and it will be your responsibility to provide an implementation for this interface. As in real systems programming, you may NOT change the interface as this is a preexisting contract with the API programmer and there may be existing software which uses this API.

The internet is of course full of plenty of reference materials for C programming, but there are different specifications and conventions, so make sure you use ANSI C and when coding conventions are specified in lecture, they should be used. Just because it works on someone else's compiler does not mean it will work on yours, and just because it works on your compiler does not mean that it is the best way to write something. Submitted code should be neatly indented and commented (you may use any style of your choosing, but your group must be consistent). It is very easy to write obscure, confusing C code. The goal of all of this is to write C that is as easy as possible for others to read and understand, which should reduce the number of bugs and security issues.

Projects will be worked on in groups of 2 or 3 students. Projects build on each other, so you will need to stay with the same group throughout the semester. Groups may not be larger than 3 students. Each member of the group should be familiar with all of the code produced by their group. You will typically be given 2 weeks to complete each project.

All students will be given a CSUG account. You are encouraged to work in these labs. Projects submissions must compile and run properly using Visual Studio on the computers in these labs, so even if you do most of your work from home or in another environment, check your project using Visual Studio in the CSUG lab before submitting. Projects will rely on library code which we will give you. You should integrate your new files into the build system used by the library code.

Writing systems code is time consuming, particularly when (not if) you have to debug problems, and most especially memory access issues, so always get an early start. Test programs will be provided with each project, but these will not be comprehensive, so will need to do your own testing as well. Good test cases will fall out naturally when you take the time to really understand abstractions and work at making reasoned design decisions, so avoid rushing into coding. Grades will for the most part correspond very directly to the effort invested.

All assignments are due on the date stipulated so that correct answers can be freely discussed after the due date. Late submissions are not accepted without prior approval from the instructor. All submissions will be via CMS.

Academic integrity violations will be prosecuted aggressively. Collaborate only with your group on the projects. Do NOT "borrow" code from the internet or anywhere else.

Classes Overview

Classes will follow a pattern based on project assignments:

The week a project is assigned, we will cover the expectations for the project, any needed theoretical details not touched on in 414, guidance for the high level design of your implementation, and hints on avoiding particularly sneaky bugs.

The following week, we will start class with a question and answer session concerning the current project. After that, the remainder of class will typically be used to present concrete real world examples of the material recently covered in 414. This material will be helpful for assignments in both 414 and 415.

Attendance is required. All students are responsible for announcements made in lecture and material that is covered in lecture. If you must be absent from a class session, make arrangements with another student to find out what you missed.

Grading Overview

Grading on projects will be based both on the software running and completing the test cases as well as on a thorough code review. All grading will be done in CSUG--after a project is submitted, groups will sign up for a project demo time slot. During this time slot, your group will show a TA the test cases being run, and then do a code walk through with the TA. All group members must lead a portion of each code walk through.

Your final course grade will be computed as follows:

90% Average of Project Grades. Your lowest project grade will be dropped. There is a possibility of an in-class lab overview quiz at the end of the semester which will be given in the event of general poor class attendance or uneven group participation. This would be taken individually and would be weighted the same as a project (though this grade would not be dropped).

10% Entirely Subjective Factors. These include attendance, class participation, and solving extra credit assignments. This portion of the grade typically affects only a handful of students, raising or lowering their final course grade by 1/2 letter grade.

Office Hours

Office Hours begin 28 January. Office Hours will be in Upson 328B, Bay A on Monday, Wednesday, Thursday and Friday from 3:30 to 5:00. The main 415 TA is Barry Burton; he will be in running the Friday Office Hour and will be available by appointment as well.



Class Schedule

Date: Content Overview:
22 January Class introduction, Projects 0 & 1, C Language Tutorial / Review
29 January Project 1 Q&A, OS Hardware Architecture Support
5 February Project 2, Thread & Semaphore Implementation Overview, UNIX Process and Thread APIs
12 February Project 1 Review, Thread Implementation Details, Semaphore Use, Design Documents
19 February Project 2 Q&A, Scheduling
26 February Design Documents, Project 3
4 March Project 3
11 March Project 3 Design Feedback
25 March Message Passing Overview
1 April Project 4 Details
8 April Project 4 Design Feedback
15 April Filesystems Overview
22 April Project 5 Details
29 April Project 5 / Class Questions


Project Assignments

Due Date: Description:
29 January Project 0 - Group Formation
Find 1 or 2 other people to work with and create a CMS group.
5 February Project 1 - Queue Data Structure
Implement a reasonable queue data structure which can be accessed using the provided API. This project should be used familiarize yourself with C, so make sure the implementation is good and bug free. You will use this code in all subsequent projects, as well.
Design Document: 18 February
Code: 25 February 		Project 2 - Cooperative Multitasking
Create a simple thread abstraction which we will call minithreads. For this project, the abstraction will be implemented as a non-preemptive thread library, including a scheduler and synchronization primitives. Using the minithread and synchronization libraries, we will then implement an application which simulates an elevator.
Design Document: 9 March
 Project 3 Design - Preemptive Multitasking
Adapt minithreads to be preemptive. Add application level alarms. Change scheduler policy to multilevel round robin with feedback and aging.
Code: 25 March
 Project 3 Code - Preemptive Multitasking
Implement the new additions and changes you previously designed. Write a benchmarking application to determine the overhead of various system actions. Use this data to fine tune the length of your scheduling quanta.
Design Document: 2 April
 Project 4 Design - Message Passing
Add a message passing abstraction which gives applications three primitive operations that enable machine independent inter-process communication.
Code: 21 April
 Project 4 Code - Message Passing
Implement the message passing system using given data structures and layers. Determine a pattern for replacing shared memory / semaphore based communication with message passing communication. Adapt your elevator application to use message passing.