Project 9

Submit: Turn in your entire xinu-hw9 directory source files using the turnin command on morbius.mscsnet.mu.edu or one of the other Systems Lab machines. Please run "make clean" in the compile/ subdirectory just before submission to reduce unnecessary space consumption.

Work should be completed in pairs. Be certain to include both names in the comment block at the top of all source code files, with a TA-BOT:MAILTO comment line including any addresses that should automatically receive results. It would be courteous to confirm with your partner when submitting the assignment.

Threads

Preparation

Make a fresh copy of your work thus far.
cp -R xinu-hw8 xinu-hw9

Then, untar the new project files on top of it:
tar xvzf ~brylow/os/Projects/xinu-hw9.tgz

Be certain to make clean before compiling for the first time.

Threads vs. Processes

The distinction between the concepts of "threads" and "processes" can be an important one. Our textbook provides the definition that processes execute in their own memory space, whereas threads share the same memory space within a process. But beyond that, most of the aspects of processes we have already studied seem to repeat for threads -- you need a thread control block, each thread gets its own stack of activation records, we need to worry about a scheduling policy for deciding which thread we will context switch to next, etc.

In truth, in the context of a simplified, embedded, educational operating system like ours, the distinction between processes and threads is not very relevant. We could label it either way, and build out the system in more concrete ways to reinforce that interpretation. In this assignment, we muddy the waters slightly further by implementing a crucial subset of the standard PThreads API using what the lightweight processes we've been working with all along.

Minor changes

In addition to the code changes below, there are a few minor changes needed to get this assignment running. The first change is a minor fix. The second and third changes are related to sharing a page table between child and parent processes. Since children and parent processes share a page table, they can't all have the same virtual address for their process stack and swaparea. Otherwise, they'd all overwrite each other! Thus, we must give threads a unique virtual addresses for a virtual stack and swap area. To do this, we take into account the PID (unique to each process and thread) when creating the virtual addresses for the thread stack and swap area. To quickly access the PID in interrupt.S, we store the PID in the tp register. We use the equation [PROCSTACKADDR OR SWAPAREAADDR] - ((pid+1) * PAGE_SIZE) to calculate the virtual address for the thread stack and swap area.

In the mapPage and mapAddress functions in map.c, change the attr parameter to a ulong.
In create.c, set the tp register to the pid of the new process. We will use the tp register to hold the current process ID.
In ctxsw.S, restore the tp register.

PThreads API

The new tarball provides an include/pthread.h header that defines the crucial #defines and function prototypes to mimic the standard POSIX PThreads interface. Chapter 27 in our textbook explains how this API works, and gives excellent examples.

The mapping of these PThread functions to existing Embedded Xinu functions is the primary content of this assignment.

pthread_create() creates a new thread, and returns its ID. We can accomplish the same work with our new ptcreate() function. We'll define pthread_t as a PID, and ignore the pthread_attr_t type as a NULL pointer. The mechanism for passing arguments to a pthread is more simplistic than our varadic argument create()
pthread_join() is an important coordination function that we do not currently have an analog for, so we must build one. When process A calls pthread_join() on a process B, process A polls the PCB of process B's state until its PRFREE. When process B terminates, process A should continue its execution. Since pthread_join() does not need special kernel privileges, it can be implemented completely in user land. Challenge/possible exam question, what could we do to improve this? Given the structures currently implemented in our operating system, what could we do to avoid the polling?
pthread_mutex_lock(), and
pthread_mutex_unlock() can be implemented as a simple spinlock based on the atomic CAS operation now provided in lock.c.

Last Call for System Calls

Each of the four PThread API functions above should be implemented as system calls by extending the trap handlers we built in Project 5: Trap Handlers.

Add new entries to the global syscall_table in syscall_dispatch.c. Note that the row in the table must correspond to the correct syscall numbers defined above. The first column in the table is the number of arguments the syscall expects.

Repeat this process for our new PThreads interface:

#define SYSCALL_PTCREATE 13 /**< PThread create */ #define SYSCALL_PTLOCK 15 /**< PThread mutex lock */ #define SYSCALL_PTUNLOCK 16 /**< PThread mutex unlock */