Problem set 5: Threads, journaling, and project


Fill out psets/ and psets/ and push to GitHub. Then submit on the grading server.

You must complete all parts by Tuesday, May 7 at 11:59pm. There will be no further extensions beyond May 7.

A. Threads

Implement multithreaded processes: processes that can have multiple independent threads of control, but that share the same virtual memory space and file descriptor table. Use kernel threads, the design where every user-visible “thread” corresponds to a struct proc.

You’ll add three system calls:

You’ll also update some existing system calls:

Run make run-testthread to check your work.

Process IDs and thread IDs

Kernel threading introduces a distinction between process and thread IDs: every user task has one of each, and they may not be equal. fork must allocate one of each.

We recommend storing the thread ID in proc::id_. This may feel backwards but it’s just easier to keep ptable indexed by id_. Add a new member, such as proc::pid_, to store the true process ID. You might add a table, such as proc* pidtable[NPROC], to store processes by true PID, but it’s also possible to rely entirely on ptable.

(For what it’s worth, Linux’s task_struct::pid member is a thread ID, while the true process ID is called a “thread group ID” and stored in task_struct::tgid. Its getpid system call returns tgid and its gettid returns pid. ¯\_(ツ)_/¯)

sys_clone interface

Your goal is for sys_clone(function, arg, stack_top) to set up a new thread running function(arg) on the given stack, where when that function returns, the thread exits via sys_texit. This means the initial thread stack frame should contain a return address pointing to sys_texit. Multithreading packages typically divide responsibility for this between the kernel’s system call and user-level code in the system call wrapper; most typically the stack setup is left to wrapper code.

Some examples from real operating systems:


In psets/, explain your synchronization plan for the process state components that can now be shared by multiple tasks. Pay special attention to pagetable_ and the file descriptor table.


Process exit is a special issue for multithreaded processes. The sys_exit system call should exit all of the process’s threads, not just the calling thread. But the process’s other threads might be blocked in the kernel or running on other CPUs! The threads’ memory and struct procs cannot be deleted until they have all stopped running. You’ll want to mark the threads as “exiting,” wake them up (unblock them), wait for them to stop running, and only then tear down the process as a whole. This will use some of the same techniques you used in problem set 2, part G (system call interruption). The later parts of check interactions between sys_exit and sys_texit.

B. Journaling (Optional)

Add journal support to your file system. This not only shows you can manage a complex on-disk structure, it also gives you practice in orchestrating a multi-part, complex parallel system to achieve a goal.

Your VFS should ensure that groups of disk writes that should be atomic are committed with a single journal transaction. For example, a free-block-bitmap write that allocates a block should commit in the same transaction as an inode write that references the block.

You may implement any journaling mode. Writeback mode, which does not write data blocks to the journal, is a fine first choice, though it has worse recovery properties than the other modes.

You may assume that the journal is empty at boot, and journal replay support is not required. (Our tests will use obj/chickdeefsck -s IMAGE, which implements offline replay.) But you may implement journal replay if you like. We recommend using the chkfs::journalreplayer base class, which implements the (complicated!) replay analysis procedure.

It can be fun to design your own journal subsystem. The critical questions are:

Give some thought to these issues. What is the simplest solution you can think of that supports allocation, matching, and ordering? But after some thought, most people should look at the in-depth suggestions.

C. Project

For this part, you should design and implement a project of your choice which adds a new feature to your operating system! Once you have an initial idea, check with the course staff to make sure that your idea is in scope and isn't too hard or too easy.

Describe your project in a file psets/ that you add to your repository. Your writeup should answer these questions:

  1. What was your goal?
  2. What’s your design?
  3. What code did you write (what files and functions)?
  4. What challenges did you encounter?
  5. How can we test your work?

The writeup need not be very long; 300 words can do it if you use the words well.

We’ve discussed project ideas in section, and will schedule a time with you to discuss more in person.