CSCC69: Operating Systems

1. CSCC69: Operating Systems Assignment 1 Some of the slides were borrowed from csc369 course, U of T, St George

2. Monitors • Locks • Provide mutual exclusion • 2 operations: acquire() and release() • Semaphores • Generalize locks with an integer count variable and a thread queue • 2 operations: wait() and signal() • If the integer count is negative, threads wait in a queue until another thread signals the semaphore • Monitors • An abstraction that encapsulates shared data and operations on it in such a way that only a single process at a time may be executing “in” the monitor

3. More on Monitors • Programmer defines the scope of the monitor • ie: which data is “monitored” • Local data can be accessed only by the monitor’s procedures (not by any external procedures • Other processes that attempt to enter the monitor are blocked. They must first acquire the lock before becoming active in the monitor. • Only a single process executes inside the monitor.

4. Assignment 1 – Task 2 • The thread system provides interrupts, control functions, and semaphores. • You will be extending the thread system of OS161 to provide additional, higher-level functions found in most thread libraries and will use that functionality to implement the process management system calls.

5. pidinfo • OS/161's threads are “processes”. • Each thread has a pidinfoblock • pidof this thread, pid of parent, exit status,… • All of the blocks are stored in a table • Access to this table must be protected since it is a shared resource • Global lock? Individual locks? • pid.c in src/kern/thread serves as a monitor to do exactly this

6. Assignment 1- Task 2 • The starter code includes a simple thread id management system (see pid.c). • The system allocates an identifier a (pid) whenever a new thread is created. • Some of the functions that allow programmers to access and use pids have been written. • You should think of pid.c as implementing a monitor that controls access to the shared pid data structures. • The externally-callable functions in pid.c are the monitor's entry points. • All access to the pid data structures (including querying or modifying any fields) must be done through a function provided by pid.c.

7. Task 2 • Read the specification and manual carefully • Think before you implement to achieve the correct solution. • Add other variable/helper functions as you need • Look at pid.c/pid.h and thread.c/thread.h • src/kern/arch/mips/locore/trap.c contains code for newly admitted processes.

8. Task 2 • intthread_join(pid_tpid, int *status) thread_join suspends the execution of the calling thread until the thread identified by pid terminates by calling thread_exit • Errors: • ESRCH: No thread could be found corresponding to that specified by pid. • EINVAL: The thread has been detached. • EINVAL: The caller of thread_join is not the parent of the thread specified by pid. • EINVAL: The pid argument refers to the calling thread. • The man pages in the OS/161 distribution contain a description of the error return values that you must return. • If there are conditions that can happen that are not listed in the man page, consider adding one. • Note that if you add an error code to kern/include/kern/errno.h, you need to add a corresponding error message to the file user/lib/libc/string/strerror.c.

9. get/waitpid() • System calls for accessing pid - user level interface • A pid, is a unique number that identifies a process. • getpid() returns the pid of the current process • waitpid() causes current process to wait on another process to exit, and get their exit status • Use the kernel threading functionalities you implement • The implementation of getpid() should be straightforward, assuming you have already taken care of allocating thread identifiers when a new thread is created • Your waitpid() system call should map nicely to the thread_join function in the kernel thread system.

10. Fork() • fork() is the mechanism for creating new processes. • It should make a copy of the invoking process and make sure that the parent and child processes each observe the correct return value (that is, 0 for the child and the newly created pid for the parent). • The core of the fork() system call will use the thread_fork() function to create a new kernel thread.

11. System Calls • User level applications are isolated from the OS in a different protection domain • System calls are a way of requesting the services of the OS • Method calls defined in user-level libraries “trap” from user-space to the OS in kernel-space • Once control traps to the kernel, a kernel-level system call handler is invoked to service the system call and return the appropriate results to user-space • Once the system call is complete, control is given back to the user-level application

12. Trap Frame • The trap frame is used to pass information about the exception, storing the current processor state for later execution • The trap handler determines which syscall is being requested by looking at the corresponding code in the trap frame struct (tf->tf_a0) • Once the syscall finishes executing, the return value or error code is put back into the trap frame (tf->tf_v0) • Read the code: taking a look at the whole call stack to get a better idea

13. OS161 System Call Example: time

14. Creating a New System Call in OS161 • Hint: take a look at what has been done for sys___time system call. You can follow the same pattern. • Define the new system call code in src/kern/include/kern/syscall.h • Define the prototypes for the new syscall • Kernel space: src/kern/include/syscall.h • User space: src/user/include • Write the source code for it in src/kern/syscall/proc_syscalls.c • If necessary, define any new error codes in src/kern/include/kern/errno.h • Complete the cases in the handler switch statement in src/kern/arch/mips/syscall/syscall.c • Test your system calls with programs in user/testbin • Rebuild both kernel and user level program

15. _exit System Call • exit only take on integer argument. • All we need to do is find our struct process entry using curthread->t_pid. • Then indicate that “I’ve exited” and fill the exitcode. The only thing to note that the exitcode must be made using the MACROs in kern/include/kern/wait.h.

16. _exit Name _exit - terminate process Library Standard C Library (libc, -lc) Synopsis #include <unistd.h> Void _exit(intexitcode); Description Cause the current process to exit. The exit code exitcode is reported back to other process(es) via the waitpid() call. The process id of the exiting process should not be reused until all processes interested in collecting the exit code with waitpid have done so. (What "interested" means is intentionally left vague; you should design this.) Return Values _exit does not return.