This lab is two one-week labs: p1t and p1s. You register once, for p1t "Thread Library", and then submit the same repo for two different deadlines. The AG tests are the same, so you will pass only a subset of the tests in your p1t submissions. The name "p1" is for historical reasons.
Code. Use your Linux docker. The code is in C++. It is wise to avoid new (C++11) features. AG support for these features is uncertain.
Spec. Read the Threads lab spec carefully, all the way through. You must follow the spec very closely to pass the AG tests. The spec describes all requirements for p1t, p1s, and your thread library test suite to be graded with p1s.
p1t. For p1t, you are expected to pass specific AG tests for creating and scheduling threads. The functionality is similar to the Week 3 activity on user-mode context switching with swapcontext. Some of that code may be useful.
p1s. For p1s, you add support for Mesa monitors to your thread library and complete your test suite.
The heap manager lab is due Monday, August 31. You may see this lab called "p0". It asks you to write C code, maybe 200-300 lines.
- Lab handout [PDF]
- 510 students should do the Extra Credit description in the lab handout, following the CS:APP reading.
The description in the lab handout is a little
misleading. Both dmalloc and dfree should be "constant time". If
your heap manager is correct, then we consider it for EC. Basically
we push your heap manager and try to make sure that alloc/free costs
do not grow (much) as we grow the size of the heap, the number of allocated
blocks, the number of free blocks, etc.: "constant time". And we
make sure that its space efficiency is above some reasonable
- Recommended reading: basic from OSTEP, free space management (ch 17) from OSTEP, advanced from CS:APP
This is the first project that will get you right into building an OS from scratch (with help).
- First setup docker desktop as described here
- Git clone this repo into a host folder shared with your container.
- The starting code is in the jos_student subdirectory. Follow the instructions in the README.md
Policies for the Labs
About the autograder (AG)
The autograder (AG) is a server that checks and grades your work and
maintains the group database. You will hate the AG at first, but
eventually your hatred will give way to grudging appreciation. The good news is that you can submit as many times as you want: the score you earn is your highest score before deadline.
Here are some things to know:
- After setting up your AG account (steps below) you register for each lab on the AG website. That creates a git repository for you, shared with us and with your team if applicable. You push your work into that repository. Then, push the button on the AG website to build and test the latest version of your repository. AG sees your commits, and you get one build/test per commit.
- The AG350 web interface is unfortunately a work in progress. Disable your ad blocker on the site (if you use one). We have seen some issues under Firefox. Be patient and click until you find what you are looking for. You can file tickets with the AG team if you are stuck. (Click help in the bottom right.)
- AG uses github. You must have a github.com account: if you don't have one please create one. Use a real e-mail address. It could be your Duke address, but any name/address will do. Install your SSH public key there in the usual way (see resources). Link your AG account to your github account:
If your browser gives you a 404 (not found) error on a github link from within AG350, check to make sure you are logged in to the selected github account (and not some other github or gitlab account) on the browser you are using, and that you accepted and have joined the AG350 repo store.
- Log into it your github account on the browser you are using for AG350.
- In a different tab of the same browser, log into AG with your NetID.
- On the AG site, link the selected github account to your AG account (upper right, Me->Accounts).
- At this step, AG talks to github, which e-mails you an invitation "to join the @DukeRepoStore organization", if you are not already a member.
- Go find that e-mail. Github sends it to the e-mail address you gave to github when you created your account. Some people say it took an hour.
- Go back to AG, register for the lab, then click the link to your github repository for the lab.
- Clone the repository with git in the usual way.
- Use the
git revision control system to
prepare your code repository exactly the way AG wants it. AG
compiles, runs, and grades your code exactly as it is in your
repository, and it expects you to follow the rules for what files you
modify and where they are in your repository. If your repository is
out-of-date, corrupt, or deformed, then the AG will give you a zero
and will not tell you why.
Like any service, sometimes the AG fails in some way and doesn't get fixed until
somebody gets to it. Nobody is wearing a pager to keep the AG
running. We have to work with the AG team and sometimes OIT for fixes.
Please be patient.
- The AG builds and runs your code on a specific version of Ubuntu Linux. If you
develop on a different system, then it is possible that your observed
behavior may differ. We suggest that you test/debug
on a machine (or container) running the same version of Ubuntu. You can
use Duke's VCM (select Ubuntu 18.04) or set up a docker container on your own machine: see
Running Linux on Windows or MacOS computers.
Using other people's code
We all know that there are various fragments of code available on the web
that are relevant to the assignments. You are not prohibited from looking at material on the
web. We believe that we have provided you with enough to start with that it will not benefit you to import source code from anywhere
else. The point of the lab is to learn, and we want to make it easy
for you to learn!
When you hand in the lab, we expect that your code
is your own. If you incorporate source code from some external
source, you must add a comment indicating the imported code and the
source of that code. You must note all sources of imported code in
your submitted README file. You should be able to explain any part
of your code in detail, and why you chose to do it that way and not some
other way. If you encounter code from some external source that
diminishes your opportunity to learn by doing the lab, please
inform us (we may not be aware of it).
Academic dishonesty. Be sure that you are familiar with the policy on
collaboration and other policies. In particular, sharing of
code among groups is not allowable. Do not
obtain code from previous semesters. Take care to
acknowledge any sources of code or assistance in your README.
About C. The first labs ask you to program in the C programming language.
We will discuss some aspects of C in lectures and recitations, and we
will provide relevant examples, but we do not teach C. If C is
unfamiliar to you, you will need to read up from some other sources,
or spend more time with the sample programs. You should
take the time to look through some of the supporting materials on the
resources page. We find that the
students who struggle most have not taken the time to read up, and as
a result they have found themselves spending more time debugging.
About Unix. To do the labs you will need a suitable Unix development
environment. If you are a CompSci or Engineering major then you have
access to Unix systems in those departments (e.g.,
login.cs.duke.edu). We can create term accounts to get access
to Unix systems in the CompSci department if you need it. Duke also
runs a virtual machine service VCM that can give you a private Unix system
for your use (select Ubuntu 18.04). You are welcome to use your own machine if it provides
a suitable Unix development environment. Docker Desktop is a good way to get an
Ubuntu Unix environment on MacOS or on Windows: see these instructions.
Once you have a command-line shell on a suitable system. You can compile C code
with the gcc compiler, and/or build programs with the
make utility. You can use the man command to learn about any C builtin library
API and/or system call API or command. E.g., try man malloc or