Hide menu

TDDI04 Concurrent programming, Operating Systems, and Real-time Operating Systems


Anmälan (endast anmälan)


Om LAB-instruktion

Som sagt kommer denna lab-instruktion utvecklas parallellt med att lab-serien framskrider. Denna kommer även att skrivas på svenska. Du som vill veta vad som skall göras och förberedas i god tid rekommenderas att istället följa förra årets instruktioner.

Du som gillar det senaste, inte har problem med barnsjukdomar, och vill kunna påverka rekommenderas att följa denna "nästa" års lab-instruktion. Du kan redan från start se ungefär i vilka steg laborationerna är uppdelade och planera därefter. Du kan naturligtvis även referera till 2009 års instruktion när du vill även om du inte följer den.

Oavsett vilken instruktion du följer skall slutresultatet vara att alla systemanrop fungerar stabilt under en längre tids körning. Det som räknas från kursens sida är inte bara att eventuella test fungerar, utan även att koden är skriven på ett tydligt och korrekt sätt. (Testfall kan fungera trots felaktig kod för obskyra fall. Korrekt kod kommer alltid klara alla testfall.)


Redovisning av laborationer sker direkt i PUL via demonstration.

Instruktion och filer

Givna filer

Lab registration

The lab sign-up is open. The labs start February 2 with a lesson. Sign Up here and NOW. If you encounter any problems with registration, please send an email describing your problem. Refer to the contact page.

The later lab pages are still subject to updates, but start reading the PINTOS documentation NOW to prepare for the labs. The most relevant parts for the first of our labs is the chapters "Project 2", "Project 3" and "Reference Guide". It is most important to get a rough picture of PINTOS and where to find the information, even if you do not understand everything yet.

General information

The assignments are done in pairs (you are not recommended to work alone), but the examination is individual. This means that it may happen that only one student in a pair receives the passing grade.

There are a total of 5 lab assignments spread over the spring periods. Refer to the course overview to see what to do each lab session. The fourth lab assignment involving exec, exit and wait are generally considered the most time-consuming, with many hours required to debug your solution.

N.B. Your task is not to make any given test program produce correct result. Your task is to fulfil the specification in a clear and efficient manner. Only minor parts of the specification is tested. You can always on will do many stupid things to fool a test program. Any test programs will work as a consequence of fulfilling the specification. If a test does not work you misunderstood the specification, or made a mistake in your implementation. The code is verified by code review, first your own, then our. Thus, it is very important to understand the specification (how the solution should behave in all possible cases).

Lab documentation



We have one final HARD deadline at the end of the course. Refer to the course overview to see what to do each lab session and the deadline. Consider the outline of each lab session given there as a (soft) deadline. If you fall behind you must catch up immediately.

Rules of the game

The laboration assignments are part of the examination in the TDDI04 course. Therefore you will have to demonstrate your solutions to your laboration assistant. And the assistant will test if you understand the solution. If it is obvious that only one student in a group of two understands the code and the concepts, then only that student will get the passing grade.

Demonstrating your solutions

Step 1: Do not waste our time, check the follow list before you demonstrate and hand in. You will be asked to correct or rewrite your code if any of the following occur (in order of easiness to fix). You are recommended to use subversion, then you can just commit a cleaned up "demonstration version" without loosing anything.

  1. Messy code
  2. Spaghetti code
  3. Old debug code
  4. Lack of relevant comments
  5. General bugs and errors
  6. Memory leakages
  7. Inefficient solutions
  8. Missing synchronization
  9. Too much synchronization
  10. Spurious test failures

Step 2: Once you have completed a lab assignment and checked the list, you should demonstrate your solution to your lab assistant. If the test programs pass correctly, and do it many times, the lab assistant will ask a couple of questions regarding the assignment, what you have done, and/or related preparatory questions.

Step 3: Send a path/svn/url to your code (should be accessible by your assistant, but not by other students). Use the script report-pintos-lab.

Pintos limitations

  • We only have one emulator, and that is qemu. This means that there is no way to get deterministic program execution with multiple user processes. (This makes race conditions more difficult to debug since you can not easily reproduce the output.)

Page responsible: Klas Arvidsson
Last updated: 2010-05-03