Table of Contents

• Document
  • Data Structures and Functions
  • Algorithms
  • Synchronization
  • Rationale
• Review
• Grading

Design

Before you start writing any code for your project, you need to create an design plan for each feature and convince yourself that your design is correct. You must submit a design document and attend a design review with your TA. This will help you solidify your understanding of the project and have a solid attack plan before tackling a large codebase. The design document will also serve as a basis for your report that you will submit.

Disclaimer: Your design document must not exceed 15 pages in length. Please do not include large blocks of code in your design document. Exceeding this limit will result in a grade penalty.

Document

Like any technical writing, your design document needs to be clean and well formatted. Please use the document answers.md in the results/ folder for your writing. Commit and push this document to your group repository by the deadline.

For each task except for Concept Check and Testing you must explain the following aspects of your proposed design. We suggest you create a section for each task which has subsections for each of the following aspects. Please use the document results/answers.md as a template for this.

Data Structures and Functions

List any struct definitions, global or static variables, typedefs, or enumerations that you will be adding or modifying (if it already exists). These should be written with C not pseudo-code. Include a brief explanation (i.e. a one line comment) of the purpose of each modification. A more in depth explanation should be left for the following sections.

Algorithms

Tell us how you plan on writing the necessary code. Your description should be at a level below the high level description of requirements given in the assignment. Do not repeat anything that is already stated on the spec.

On the other hand, your description should be at a level above the code itself. Don’t give a line-by-line rundown of what code you plan to write. You may use small snippets of pseudo-code or C in places you deem appropriate. Instead, you need to convince us that your design satisfies all the requirements, especially any edge cases. We expect you to have read through the PintOS source code when preparing your design document, and your design document should refer to the appropriate parts of the PintOS source code when necessary to clarify your implementation.

Synchronization

List all resources that are shared across threads and processes. For each resource, explain how the it is accessed (e.g. from an interrupt context) and describe your strategy to ensure it is shared and modified safely (i.e. no race conditions, deadlocks).

In general, the best synchronization strategies are simple and easily verifiable. If your synchronization strategy is difficult to explain, this is a good indication that you should simplify your strategy. Discuss the time and memory costs of your synchronization approach, and whether your strategy will significantly limit the concurrency of the kernel and/or user processes/threads. When discussing the concurrency allowed by your approach, explain how frequently threads will contend on the shared resources, and any limits on the number of threads that can enter independent critical sections at a single time. You should aim to avoid locking strategies that are overly coarse.

Rationale

Tell us why your design is better than the alternatives that you considered, or point out any shortcomings it may have. You should think about whether your design is easy to conceptualize, how much coding it will require, the time/space complexity of your algorithms, and how easy/difficult it would be to extend your design to accommodate additional features.

Review

After you submit your design doc, you will schedule a design review with your TA. During the design review, your TA will ask you questions about your design for the project. You should be prepared to defend your design and answer any clarifying questions your TA may have about your design document. The design review is also a good opportunity to get to know your TA for participation points.

Grading

The design document and design review will be graded together. Your score will reflect how convincing your design is, based on your explanation in your design document and your answers during the design review. If you cannot make a design review, please contact your TA to work out an arrangement. An unexcused absence from a design review will result in a 0 for the design portion.