#
BASE=sigcse2009
-$(BASE).pdf: $(BASE).tex introduction.tex abstract.tex $(BASE).bib principles.tex assignments.tex figures.tex
+$(BASE).pdf: $(BASE).tex introduction.tex abstract.tex $(BASE).bib principles.tex assignments.tex figures.tex \
+ rest.tex
pdflatex $(BASE).tex
-bibtex $(BASE)
pdflatex $(BASE).tex
-
-Tend to write the abstract last.
+Pintos is an instructional operating system, complete with documentation
+and ready-made, structured assignments that introduce students to the
+principles of multi-programming, scheduling, virtual memory, and file systems.
+By allowing students to run their work product on actual hardware,
+rather than only in simulated or emulated environments, Pintos can
+increase student engagement. Unlike tailored versions of commercial
+or open source OS such as Linux, Pintos is designed from the ground up
+from an educational perspective. Finally, Pintos includes a set of
+debugging, diagnosis, and dynamic analysis tools to reduce the complexity
+of kernel-level development.
the timer interrupt handler to unblock those threads whose wakeup time has arrived.
Students learn how to protect data structures that are shared between a thread and an
interrupt handler. The second part of the project constitutes a strict priority-based
-uniprocessor scheduler. In this model, one of the threads with the highest priority
-always runs. When a thread's priority changes, or when threads block or unblock,
-a scheduling decision must be triggered to ensure this invariant. Students learn about
-the different ways in which such situations occur.
-Project 1 also introduces synchronization primitives such as semaphores, locks,
-and condition variables. The project explores the interaction between such primitives,
-thread states, and the scheduler.
-
-Based on the priority scheduler, students implement two additional tasks: priority
-inheritance and a multi-level feedback queue scheduler. Priority inheritance is a way
-to avoid priority inversion, a phenonemon that most famously led to an almost-failure
-of the Mars Pathfinder Mission. We use this example to motivate
-the problem. Implementing priority inheritance correctly requires a deep understanding of the
-interaction of threads and locks.
+uniprocessor scheduler; students learn about the different ways in which
+such a scheduler must react to thread state changes.
+% cut for length
+%Project 1 also introduces synchronization primitives such as semaphores, locks,
+%and condition variables and explores the interaction between such primitives,
+%thread states, and the scheduler.
+
+Based on the priority scheduler, students implement priority inheritance,
+which deepens their understanding of the interaction of threads and locks.
+We use the example of the near-failure of the Mars PathFinder mission to motivate
+the need for priority inheritance.
Separately, students build a multi-level feedback queue scheduler on top of the strict
-priority scheduler. This scheduler adjusts threads' priority based on a sampling of how
-much CPU time a thread has received recently.
+priority scheduler. This scheduler adjusts threads' priorities based on a sampling
+of how much CPU time a thread has received recently.
\paragraph{Testing and Grading}
Project 1 is accompanied by 27 tests as shown in Table~\ref{table:tests}, which are
Usually, a test failure leads students to study the documented source code of the test
and understand how the expected output derives from it.
-The MLFQS scheduler tests are graded in a different way. Since those tests rely on estimating CPU
+The MLFQS scheduler tests are graded differently. Since those tests rely on estimating CPU
usage, they depend on how much CPU time a specific implementation uses, which in turn depends on how
efficient it is. We compute the expected CPU consumption values by simulation and provide an
-envelope within which we accept the output. The envelope is large enough to allow for minor
+envelope within which the output is accepted. The envelope is large enough to allow for minor
inefficiencies, but major inefficiencies will usually lead to test failures. Such failures
convey the importance of using efficient algorithms and data structures within a kernel,
because wasting CPU cycles in the kernel reduces the amount available to applications.
Although Pintos follows in the tradition of instructional operating systems
such as Nachos~\cite{Christopher1993Nachos}, OS/161~\cite{Holland2002New}, and
GeekOS~\cite{Hovemeyer2004Running},
-PortOS~\cite{Atkin2002PortOS},
+PortOS~\cite{Atkin2002PortOS}),
BLITZ~\cite{PorterOverview},
JOS~\cite{1088822}, or Yalnix~\cite{1088822},
we believe that it is unique in two
aspects. First, Pintos runs on both real hardware and in emulated and
-simulated environments.\footnote{GeekOS claims to also run on real hardware, it requires,
-however, a dedicated disk and does not support running off USB devices, making
-it impractical for many lab settings.}
+simulated environments.\footnote{\small GeekOS is the only other system that claims to
+also run on real PC hardware; it requires, however, a dedicated disk and
+does not support running off USB devices, making it impractical for many
+laboratory settings.} We believe that having the ability to see the outcome
+of their project interact with actual hardware increases student engagement.
Second, we have created a set of analysis tools
for the emulated environment that allows students to detect programming
mistakes such as race conditions. Figure~\ref{fig:pintosenvs} shows
a similar level of realism to students in that they can see the result of their
work on concrete or virtualized hardware, but does not require that students
understand the often arcane and ill-documented interfaces of the Linux kernel,
-which were not designed from an educational perspective.
+which were not designed from an educational perspective. By contrast, all
+Pintos code is written to be studied by students.
-This paper summarizes the design philosophy that underlies Pintos,
-details its structure, and outlines the nature and learning goals of each
-assignment.
+%This paper summarizes the design philosophy that underlies Pintos,
+%details its structure, and outlines the nature and learning goals of each
+%assignment.
\pintosenvfigure{}
We also considering the extension of Pintos to multiple
CPUs, and the development of assignments that involve
networking and interprocess communication (IPC).
+Although feedback from our industrial affiliates, who compare
+students having Pintos to students having taken course that use
+less concrete or external approaches, is highly favorable,
+we need to perform a formal evaluation comparing learning
+outcomes using Pintos to other alternatives.
posted-at = {2008-08-29 02:18:53},
priority = {2},
publisher = {ACM},
- title = {Using iPodLinux in an introductory {OS} course},
+ title = {Using {iPodLinux} in an introductory OS course},
url = {http://dx.doi.org/http://doi.acm.org/10.1145/1352322.1352199},
volume = {40},
year = {2008}
pages = {520--524},
posted-at = {2008-08-20 04:36:38},
priority = {2},
- publisher = {ACM Press},
- title = {Experiences teaching operating systems using virtual platforms and linux},
+ publisher = {ACM},
+ title = {Experiences teaching operating systems using virtual platforms and {Linux}},
url = {http://portal.acm.org/citation.cfm?id=1047508},
year = {2005}
}
@inproceedings{Hovemeyer2004Running,
address = {New York, NY, USA},
author = {Hovemeyer, David and Hollingsworth, Jeffrey K. and Bhattacharjee, Bobby },
- booktitle = {SIGCSE '04: Proceedings of the 35th SIGCSE technical symposium on Computer science education},
+ booktitle = {SIGCSE '04: Proc. of the 35th SIGCSE technical symposium on Computer science education},
citeulike-article-id = {3138451},
doi = {10.1145/971300.971411},
isbn = {1581137982},
projects / pintos-anon / commitdiff