Skip to main content

Checkpoint Gate

Required Output Classification​

Required outputClassificationPublic/private guidance
Closed-book prompts, self-assessment answers, and skills matricesPractice artifactUse for honest calibration; do not publish raw answers unless rewritten as a study guide.
Required evidence gate items, sign-off checklist, and readiness decisionCheckpoint evidenceKeep as private progression evidence; share only sanitized summaries with mentors or reviewers.
Repair artifacts produced after a weak checkpoint, such as corrected solutions, diagrams, traces, benchmarks, or runbooksCheckpoint evidenceStore beside the checkpoint so the remediation trail is inspectable without making mistakes public.
Reviewer notes or mentor feedback that materially improve a project artifactPortfolio candidateConvert into public-safe acknowledgements or changelog entries only after removing private feedback context.

Use this gate before moving to Semester 6. The standard is not "I saw the material once." The standard is "I can reason through it from memory and support claims with traces, measurements, or working code."

How To Use This Gate​

For each item, mark one of:

  • Confident if you can answer or perform it now, from memory
  • Review needed if you would need notes, prompts, or another practice pass

If two or more items in the same module are weak, return to that module before advancing.

Knowledge Checks​

Module 1: Processes & Scheduling​

  1. I can compare FCFS, SJF, SRTF, round-robin, and MLFQ on a small workload and compute turnaround and response time. [ ] Confident [ ] Review needed
  2. I can explain a context switch step by step, including why cache and TLB effects matter. [ ] Confident [ ] Review needed

Module 2: Memory Management & Virtual Memory​

  1. I can walk a virtual address through a multi-level page table and distinguish TLB miss from page fault. [ ] Confident [ ] Review needed
  2. I can explain replacement-policy tradeoffs, allocator roles, and when mmap or CoW changes performance behavior. [ ] Confident [ ] Review needed

Module 3: Concurrency & Synchronization​

  1. I can write the interleaving that breaks naive shared-memory code and explain the smallest correct fix. [ ] Confident [ ] Review needed
  2. I can use mutexes, condition variables, semaphores, and lock-ordering rules without confusing safety, liveness, and fairness. [ ] Confident [ ] Review needed

Module 4: File Systems & I/O​

  1. I can explain what write() returning does and does not guarantee, and how journaling or CoW changes crash outcomes. [ ] Confident [ ] Review needed
  2. I can justify when to choose blocking I/O, epoll, or io_uring for a service. [ ] Confident [ ] Review needed

Module 5: Network Protocols & Sockets​

  1. I can do subnet reasoning, explain TCP state transitions, and distinguish flow control from congestion control. [ ] Confident [ ] Review needed
  2. I can write and debug a socket server using packet and socket-state tools rather than guesswork. [ ] Confident [ ] Review needed

Skills Checks​

  1. I have at least one working scheduler, memory, concurrency, filesystem/I/O, or networking artifact that I can run and explain. [ ] Confident [ ] Review needed
  2. I have used real inspection tools this semester such as perf, strace, /proc, ss, tcpdump, or Wireshark and wrote down what I observed. [ ] Confident [ ] Review needed
  3. I can take one bug or performance complaint and turn it into a concrete hypothesis, measurement plan, and written conclusion. [ ] Confident [ ] Review needed
  4. I can explain how this semester feeds directly into databases and distributed systems next semester. [ ] Confident [ ] Review needed

Required Evidence Before Advancing​

You should be able to point to:

  • one process or scheduler artifact
  • one memory or page-fault measurement note
  • one concurrency exercise with a documented broken interleaving and fix
  • one filesystem or I/O measurement or crash-consistency note
  • one network capture or working socket service

If you do not have evidence for one of these areas, the semester is incomplete even if your notes look good.

Common Blockers To Resolve First​

Do not move on if any of these are still true:

  • you confuse a TLB miss with a page fault
  • you cannot produce a deadlock example and name the condition your fix removes
  • you treat write() success as "durable on disk"
  • you cannot explain TIME_WAIT, CLOSE_WAIT, or why epoll scales better than select
  • you have no packet capture, no perf output, and no actual measurements from the semester

Sign-Off​

  • I completed the cumulative review
  • I completed the semester exam
  • My semester project and module artifacts are runnable or clearly documented
  • I am ready to begin Semester 6: Databases & Distributed Systems

Mastery Rubric​

LevelEvidence
Beginner passCan answer direct questions and complete familiar exercises with light notes.
Solid passCan solve new variants, explain choices, and connect the work to Semester 4 Systems Programming.
Strong passCan defend tradeoffs, identify failure modes, and produce clean evidence in the portfolio artifact.
Not readyRelies on copied solutions, cannot explain mistakes, or lacks durable artifacts.

Retake and Repair Rule​

If a section is weak, do not only reread. Repair it by producing new evidence: a corrected solution, a fresh implementation, a rewritten proof, a benchmark, a diagram, a runbook, or a short teaching note.

Answer-Quality Examples​

Use these examples when grading written answers or spoken explanations.

QualityExample pattern
WeakNames a concept but gives no example, constraint, or failure case.
AcceptableDefines the concept and applies it to a familiar exercise.
StrongApplies the concept to a new variant and explains why an alternative would fail.
Portfolio-readyConnects the concept to Semester 4 Systems Programming, current project evidence, and a future capstone decision.

Interleaving Prompt​

For any missed answer, add one sentence starting with: This depends on an earlier skill because...​

Calibration Materials​

Use these learner-visible calibration materials before self-grading or requesting review: