6: Adding threading support to xv6

In this homework, we make some major changes to xv6 to add support for kernel threads to the OS. A single process may execute multiple kernel threads, which may operate concurrently on a multi-core machine.

The hw6 template already includes some significant refactoring. The main changes are the replacement of the "proc" global with a "current" global, which holds the current thread. Also, the ptable is an array of struct thread instead of struct proc, where each struct thread has a pointer to a potentially shared struct proc.

However, in the template there is a one-to-one mapping between threads and processes. Your job is to make that a many-to-one mapping by adding thread management facilities and enforcing correct thread semantics on existing system calls.

Basic Thread creation Heading link

With fork(), a process is copied wholesale. A skeleton exists for the system call sys_clone(). Complete the implementation, to make each of the thread test cases (programs thread1..threadN) work correctly.

As is usually the case, it’ll be easier if you do things a step at a time. For thread creation, I would suggest:

  1. make thread1 print hello world, by a little bit of code in clone that sacrifices the original thread
  2. make thread1 print both hello world and hello from main, by forking off a new thread
  3. make thread2 print a bunch of numbers by setting up shared memory

thread_exit() Heading link

You’ll find that the third test case, thread3 crashes at the end of its run. When the created thread has finished running f() it tries to return to the calling function, but it doesn’t exist.

  • make thread3 not crash by adding a system call thread_exit (to test, temporarily add a call to thread_exit at end of f)
  • update thread_create in ulib.c to have created threads automatically call thread_exit when their initial function returns

Process exit() semantics Heading link

When any thread calls exit(), the process should die, which means all threads should stop executing. Update the implementation of the exit() system call to reflect this behavior.

Without this fix, thread3b will crash after it has finished executing the function f(), as the main thread calls exit() before f() is done. exit() then frees the process memory, while f() continues to execute. To fix this, exit() should kill all threads before freeing memory.

thread_join(): waiting for threads to finish Heading link

With the correct exit(), thread4 will finish before f() gets a chance to do its job. The thread4 code includes a call to thread_join(). Here, the main thread should wait for the other thread to finish before continuing.

Provide a real implementation of thread_join(), including a new system call sys_thread_join() to support this behavior. Additional test cases in thread4b.

With the correct exit(), thread4 will finish before f() gets a chance to do its job. The thread4 code includes a call to thread_join(). Here, the main thread should wait for the other thread to finish before continuing.

Provide a real implementation of thread_join(), including a new system call sys_thread_join() to support this behavior. Additional test cases in thread4b, thread4c and thread4d.

exec() semantics Heading link

The final test case, thread5, uses exec() to start a new program (thread5_helper), while another thread is running in the background. The expected behavior is for the other thread to stop running, and for thread5_helper to write its output to the screen, then exit.

turn-in Heading link

As usual, follow this invitation link  to create your personal github turn-in repository.