Skip to content

Latest commit

 

History

History
179 lines (138 loc) · 8.15 KB

15410.md

File metadata and controls

179 lines (138 loc) · 8.15 KB
Raw

15-410: Operating Systems

Category Difficulty
HW 3
Projects 8
p3 10
Exams 8

OS is one of the most infamous courses at CMU, known for its difficulty, and grueling assignments and exams. As difficult as it may be to get a good grade, most students can agree they will learn invaluable skills and habits from this course, regardless of their final grade.

In addition, much of the difficult of OS comes from the structure of the course, which can be ambiguous in asking for what they want, and not providing a whole lot of direction.

This guide will attempt to clear up some of these ambiguities and give pointers to future students who want to run the relentless, but rewarding gauntlet of OS.

Lectures

The course staff recommends students attend lecture. While you could probably survive OS without attending lecture, there are tips and warnings given by the course staff during lectures that can help you with your projects. Lectures do not feel concretely rewarding as a lecture on algorithms might be, where you walk out with a tangible new skill, but if you go to them with a willing attitude, you can properly apply a lot of the tips to your code.

The lectures do a good job of giving high-level ideas of what the course staff is looking for, and has tons of content to absorb.

However, the introduction to these topics can be quite cursory, and unless you already have a background in the subject, you may not be able to fully understand what the course staff is trying to tell you. For example, the course staff might warn you about race conditions, but you don't really feel the pain of race conditions until you experience them for yourself during a bug in one of your projects.

Projects

Projects are the core of OS. They give the student a chance to not only implement systems-level projects, but also test a student's ability to apply all the good practices that the course staff wants to teach the student, which include

  • Synchronization safety
  • Readability
  • Style
  • Modularity
  • Testing

You should think of your projects as "products," and anything from something that could be sold to the public is not good enough.

p3

Essentially the face of the course, p3 is difficult for many reasons

  • You have to write a lot of code. Usually around 10k+ lines.
  • There is not much guidance for how to implement anything, so you have to figure it out yourself. This also gives you opportunities to make bad design choices and make your life difficult later down the road.
  • Bad design choices will destroy you if you don't fix them early on
  • Large-scale synchronization-safe code is very difficult to write properly.

The p3 handout is probably the best resource you have for getting started on the assignment. There are also some other resources you should consult to do the project.

  • Switching to User Mode: Good guide about context switching.
  • What I Wish I Knew for p3: Reflections about p3 from a former student
  • intel-sys.pdf: Course staff provides a copy and you can also find it online.
  • OSDev Wiki: Wiki where you can find partial implementations of portions of your OS

Exams

Exams are very difficult in the class. To quote a friend,

OS brings out all the mistakes you don't usually make

Although this will sound cliche, OS will bring the worst version of you on Exam Day. You will have poor time management when you normally don't, you will miss deadlocks when you've already seen so many during prep, and you'll get stuck when you thought you'd have a backup just in case you'd get stuck.

However, despite how hard exams are, they can be well-prepared for. There are lots of materials available for preparation, and even past exams to reference.

Exams are usually formatted as:

  • Testing a good practice explained in lecture, such as error checking, decision matrices, how to panic, etc. This can also just be a straightforward concept, like what is 1:1, n:m kernel threading, how does transactional memory work, etc.

  • Deadlock question: You are given some code or a scenario, and you have to find deadlock. In general, you should always know the 4 conditions for deadlock, and how to resolve them.

  • Synchronization Issue: Usually asking for a race condition, and a code trace that demonstrates the race condition happening. A followup question will ask you how to resolve the race.

  • Reading Assembly: You will be given a snippet of assembly, and you have to figure out what it does and maybe figure out any vulnerabilities to it. You are also often asked to draw a picture of the VM associated with running the assembly. You often don't have to write that much assembly code until p3, so be ready for one of these questions for the midterm.

  • Writing Tests: You are asked to write black-box testing code for some sort of program or function, such as a mutex. You need to be able to come up with all the mistakes a student could possibly make with their mutex implementation.

The best prep for exams is to do the practice exams found at the 410 Exam Archive. I feel like these exams would be more useful if they had solutions, so if anyone wants to start a solutions archive...

HW

There are few HWs in the class, and they don't usually count for much. If anything, they are usually used to just quiz simple lecture concepts, or give you an exercise in preparation for a format of an exam question. For example, you might be given a HW about code tracing, which helps you understand what format the course staff wants you to respond in to a similar question on the exam.

How to do well

  • As important as it is to complete your assignments on time, code quality reigns supreme over almost any time advantage you might get from finishing your projects early, but with little quality. This is because the projects are often large enough in scale where bad code is almost unfixable at the end. Therefore, spend enough time justifying good code choices early on, and don't rush to just "get it done."

  • There is a large myth surrounding how grading is done in the class. Although no one knows for sure, the general consensus is that the biggest weights are on p3 and the exam grades. This is not to say to just throw away your grades for the other projects and HWs, but if you get Cs on the earlier projects, it is ok. You should use these grade penalties as opportunities to learn and prepare for p3 and exams. Therefore, as long as you prepare for your exams well and do well on p3, you should be able to get a good grade. Obviously easier said than done.

  • It might feel discouraging to ask questions, since the course staff can often give vague responses to your questions. Despite this difficulty, you should still try to ask questions where you have them, and if you get a response that feels like you asked a bad question, try to modify your question so it is better.

  • Learn how to use macros to make your code more modular. Anything from simple #define for constant values to defines that take in arguments and can be used to construct functions are all very useful. You can also use them to create your panic statements and any debugging protocols.

  • In your synchronization code, always make sure that they don't violate the requirements:

    • Mutual exclusion
    • Progress
    • Bounded Waiting

  • Reading the textbook can be surprisingly rewarding. Although you won't necessarily get everything you want, you will be given code implementations, examples, and more elaboration on concepts.

Resources