Homework6 < CS385

CS385 Web>Homework6 (2017-03-25, Main.jakob) (raw view)EditAttach
---++ 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

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
   1 make thread1 print both hello world and hello from main, by forking off a new thread
   1 make thread2 print a bunch of numbers by setting up shared memory

---+++ thread_exit()

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

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

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= as well as the poorly named =thread3c= and =thread3d=.

---+++ exec() semantics

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.
Topic revision: r2 - 2017-03-25 - 16:49:55 - Main.jakob
CS385
WISEST
Helping Women Faculty Advance
Funded by NSF