lunduniversity.lu.se

Computer Science

Faculty of Engineering, LTH

Denna sida på svenska This page in English

Project: PintOS Extensions

Introduction

For the project, the goal is to add more functionality to your PintOS such that more and more tests pass when you run make check in the different directories. The instructions for the project are less detailed than for the lab assignments which means that you may need to spend more time on reading and understanding the PintOS documentation and sources. You should implement three distinct features for the project: read-only executables, priority scheduling and memory-mapped files. You are welcome to implement more features if you wish, but make sure in any case that all previous tests still pass.

Learning outcomes

After completing the project you will have a deeper understanding of specific OS features such as protection, scheduling with priorities, and memory mapped files. You will also understand better how the different services and features impact each other.

Part 1: Read-Only Executables

Add code to deny writes to fi les in use as executables. See section 3.3.5 in the PintOS documentation for details. The amount of code you will need to write for this is minimal. Working directory: src/userprog. Tests to pass (besides all the other tests from the labs and project - your new code should not break those):

tests/userprog/rox-simple
tests/userprog/rox-child
tests/userprog/rox-multichild

Part 2: Priority Scheduling

Implement priority scheduling in PintOS. See section 2.2.3 in the PintOS documentation for details. For testing, use the src/threads directory with make check (the mlfqs tests will not need to pass for this part). Making sure that threads run according to the given priorities is not that complicated, but getting the inheritance (priority-donate-* tests) right will require gradual and thorough design.

Hints

Following are a few hints to help you towards a possible implementation. You do not have to follow these, you are free to implement your own solutions.

  • use a list of held locks in each thread (best if this is kept ordered!)
  • introduce a dictator variable for each lock (pointing to the thread that will determine the priority of the lock holder)
  • compute the thread priority based on the list of held locks (i.e. the highest priority of the dictator threads)
  • careful with possible infinite loops when computing the priority based on these structures
  • any time the dictator of a lock changes, the list of the held locks of the holder must be re-sorted
  • the priority-donate-lower test will require you to lower a thread's priority in a delayed manner; save the wanted priority in another variable and update based on this only when nobody else dictates the thread's priority

Note: do not forget to keep checking that the rest of the configurations work. make check in src/vm should still work fine! In some cases thread_yield in sema_up can cause serious failures hard to identify - make sure you only call this if the next thread to execute has higher priority and not during an interrupt context.

Part 3: Memory Mapped Files

See sections 4.1.7 and 4.3.4 in the PintOS documentation for details. Working directory: src/vm. Tests to pass: all the tests matching tests/vm/mmap-* as well as tests/vm/page-merge-mm.

Hand-in

  • Motivation for the code added in each of the parts.
  • The modified PintOS source code (one version! not three different for each part) that is passing all the make check tests as specified for each part. Naturally, the tests for the labs should still pass.

Observation

  • The estimated time needed to complete the project is much less than 80h (expected 4h + 24h + 36h), which would amount to 3 credit points. However, adding the work done for lab 0, will bring up your total to 80h for the project.