In doing OS161 assignments, if you don't know how to use GDB and how to use it efficiently, you're screwed, and will die very ugly. It's a very important skill to use GDB to identify what's wrong with your code. That's the first step towards to fix the bug.

When working on OS161 system calls, you'll probably see a bunch of this error, especially you haven't implemented _exit syscall and try to do some basic user programs, e.g., p /bin/true.

Note, this problem has been fixed in OS/161 version 1.99.07.

This post shows how to install os161 toolchain, including bmake, sys161, etc. on your local machine.

The idea of Reader-Writer Lock is quite simple. In normal lock, we don't differentiate the threads. That said, each thread who wants to enter the critical section must first acquire the lock. But on a second thought, you may find that threads actually have different behavior inside the critical section: some threads just want to see the values of shared variable, while others really want to update those variables.

Condition variable is used for a thread to wait for some condition to be true before continuing. The implementation is quite simple compared to lock, yet the difficult part is to understand how a CV is supposed to used.

Lock is basically just a semaphore whose initial counter is 1. lock_acquire is like P, while lock_release is like V. You probably want to go over my previous post about semaphore

Semaphore denotes a certain number of shared resources. Basically, it's one counter and two operations on this counter, namely P and V. P is used to acquire one resource (thus decrementing the counter) while V is used to release one resource (thus incrementing the counter).

When you finished the process system call (e.g., fork, execv) and test your system call by executing some user program, you'll probably find that the console input behavior is messed up.

There are several SAME_STACK asserts in $OS161_SRC/kern/arch/mips/locore/trap.c to ensure that current thread did not run out of kernel stack.

Sys161 will panic if you try to write a TLB entry with a entryhi, but there are already a TLB entry with the same entryhi but in a different TLB slot. This is because entryhi should be a UNIQUE key in the TLB bank.