Project overview

The goal of the project is for you to define how you spend your last few weeks of the term. You should implement some new idea, or expand further something we’ve done so far, in a way that interests you.

See below for project ideas. You can also propose ideas of your own.

Scope

The scope of the project should be roughly one lab assignment. You can work with a partner, including submitting a single proposal and single codebase.

Goals

The goals of the project are six-fold:

1. Explore some copying/paging mechanism, synchronization protocol, scheduling algorithm, or other topic in Operating Systems in more detail.
2. Implement something related to your chosen topic.
3. Write test cases to validate the correctness of your implementation.
4. Perform experiments comparing to other mechanisms, protocols, schedulers, etc., or otherwise demonstrating the effectiveness of your implementation.
5. Write up your results in the format of a conference paper (in 3-4 pages).
6. Present your results to your peers.

Partners

You are allowed to work on the project with a partner, and for each deliverable, submit only one for the pair. This means that you can work together on the code, and do not need to type it up separately.

Deliverables

There are four deliverables for this project:

• Proposal, due Tuesday 2/20/24
• Code, due Friday 3/1/24
• Paper, due Wednesday 3/6/24
• Presentation, likely on Wednesday 3/6/24

You can use tokens on these pieces, but doing so could cause additional time pressure later, so be cautious:

• You can use one token for an extra 24 hours on the proposal, although you really do want to get the project proposal okayed as soon as possible.
• You can use one token for an extra 72 hours on the code, but that will make it a bigger time crunch to finish the paper and prepare the presentation.
• You can use one token for an extra 48 hours on the paper, but having the paper written will make the presentation much easier to prepare.

By college policy, a class with a final can have no work can be extended into reading days, so everything must be submitted by 10pm on the last day of classes.

Proposal

Your proposal should be about 1 page, and describe the following:

• Whether this project represents a pair or an individual
• What your project idea is (this should be a paragraph)
• What functionality you plan to implement
• Two or more tests you will write (names and high-level descriptions)
• Three or more references (e.g., conference papers, textbook chapters, or websites) that your work will reference as background materials
• What information you don’t have yet that you still need (topics you should read papers on, etc.)
• What issues you foresee in advance

Think of your proposal as a lighter version of a design documentation. Here is an example template (raw file) that you can follow. Example proposals are given below.

You should submit your proposal on Gradescope by 10pm on Tuesday 2/20/24.

Code

Your program should be of the scope of one lab assignment, and include the following:

• Implementation of your project.
• At least four test cases to validate your functionality.

You should submit the code on Gradescope by 10pm on Friday 3/1/24.

Paper

You should submit a 3-4 page paper, comprised of the following sections:

1. Introduction describing your project
2. Background information necessary to understand your project, including references you had to read to complete the project
3. Details of code you implemented
4. How you tested your code to ensure it was correct, and/or experimentation results and discussion
5. Conclusion

Additionally, you should have a title, abstract, and references. Both Latex and Word templates are available from IEEE. You are strongly encouraged to use Overleaf for Latex, especially if you haven’t used Latex before, as it can help give a gentle introduction. Here are two example papers to look at to get a feel for the style: paper 1 and paper 2.

Presentation

Presentations will be during class in Week 10. You will find the presentation order (once it’s decided in Week 9/10) in an announcement on Slack.

Your presentation (either for an individual or a pair) should take approximately 4 minutes, with up to 2 minutes allowed for questions. Note that this will go much faster than you’d expect, so it’d be good to practice at least once. Here is a general guideline for what you should cover:

1. Contributions (30 seconds): the goal of your project
2. Method (2 minutes): a simple example describing your project (e.g., a diagram describing how copy-on-write works, or a schedule for a new scheduler)
3. Results (1 minute): a graph/plot of what you measured or observed
4. Future work (30 seconds): what you would have done next if you had had more time/motivation

You are welcome to use slides. If you do, you should email them to me by 11:00am the day of your presentation.

If you do not wish to make slides, you should plan to sketch the example on the blackboard, and email the plot/schedule to me before 11:00am the day of your presentation.

Project ideas

The simplest idea is to implement what would have been Lab 5: Copy-On-Write. Here is the Lab 5 page from when this course was last taught. If you choose this option, you will need to additionally do the following:

• Implement a time() system call to get some measure of the passage of time. You should talk to me about this, and/or find the variable ticks in time.h and think about how to expose it.
• Add two additional test cases to those available for the lab.
• Experimentally measure the time used to call fork() a bunch of times with and without your copy-on-write implementation.

Alternatively, you are welcome to propose your own project. This could be:

• changing out the scheduling logic (which we have not touched, but we’ll talk about scheduling in Week 8), and maybe measuring the time until a given process/thread completes based on a given priority
• performing experiments on different versions of proc_wait() that either use busy-waiting loops or condition variables, to see how long each test takes in either case
• adding a bunch of system calls you wish were there
• diving into how the file system works and making some change there

Here is an example proposal.