lecture 7 notes good to go
authorKyle Spaans <kspaans@student.math.uwaterloo.ca>
Tue, 26 May 2009 23:23:48 +0000 (19:23 -0400)
committerKyle Spaans <kspaans@student.math.uwaterloo.ca>
Tue, 26 May 2009 23:23:48 +0000 (19:23 -0400)
lec07-0526.tex [new file with mode: 0644]

diff --git a/lec07-0526.tex b/lec07-0526.tex
new file mode 100644 (file)
index 0000000..25b32e9
--- /dev/null
@@ -0,0 +1,75 @@
+\documentclass{article}
+\usepackage{fullpage}
+\usepackage{amsmath}
+\author{Kyle Spaans}
+\date{May 26, 2009}
+\title{Operating Systems Lecture Notes}
+\begin{document}
+\maketitle
+
+\section*{Lecture 7 -- Deadlocks and Processes}
+For assignment A1, note that the CV's functions are only supposed to be called
+from inside of a critical section. I.E. the lock parameter should be checked to
+make sure the calling thread holds it.
+
+\subsection*{Deadlock Detection and Prevention}
+We look at an algorithm for detecting deadlocks, given a ``graph'' describing
+the allocated resources, requested resources, and thread states. Constantly
+checking this is expensive though. Alternatively we can have strategies to
+prevent deadlock.
+
+``No Hold and Wait'' notices that we only get deadlock because we can wait on
+a resource while also holding some resources. We only let threads acquire
+one or more resources at one time and force them to release those before
+requesting more. This will prevent deadlocks.
+
+``Resource Ordering'' lets us put restrictions on the order in which resources
+are allocated. This means that we can't have cyclic dependancies. Each resource
+is assigned an increasing number $i$. After allocating resource number $i$, a
+thread can't allocate any more resources of number $\le i$.
+
+\subsection*{Processes}
+Processes are an abstraction of a program's encapsulation. A ``process''
+carries around a bunch of extra information about itself: open files, sockets,
+attributes, virtual memory. All of this is shared between the one or more
+threads that are part of the process. Multiprogramming, therefore, means
+basically multiple processes (each possibly with multiple threads). Processes
+also keep programs isolated from each other. This means if a program crashes,
+it can't hurt or disrupt it's neighbour.
+
+Remember that the kernel is just a program like any other. The difference is
+that it runs in privileged mode. It can exectute privileged instructions
+(change CPU state) and access certain memory addresses that regular programs
+can't. The kernel even has it's own slice of memory that's kept seperate from
+other programs. Normal programs should not be able to modify any of the
+kernel's code or data. The kernel is not, however, a process. We'll learn more
+about this soon.
+
+\subsection*{System Calls}
+System calls are the interface that the kernel provides to userspace. They are
+like procedure calls, except that they run in a different memory address space
+and they are run in privileged mode. Because it is kernel code that makes up
+the body of the system call, it naturally runs in the kernel's address space
+and runs at the kernel's privilege level.
+
+System calls are supported by
+machine dependant instructions (\texttt{syscall} in the case of MIPS, and
+\texttt{int 80h} or some such on x86). This is necessary in order to change
+the privilege level of the code (normal procedure calls can't do this). This
+essentially means that a system call causes a software interrupt, which jumps
+into the exception handler, which notices that a system call has occurred and
+jumps to the correct procedure in the kernel. The special instruction will also
+do some custodial work, such as saving the PC into \$29 (RA).
+
+Function prototypes, in \emph{OS161} are defined in \texttt{unistd.h}, and each
+system call has a man page describing it. Our userspace application gets linked
+with the standard library, which wraps around system calls. So if we look at a
+disassembled program (see course notes) we'll notice that our system call gets
+compiled into a regular procedure call. This jumps into the part of the
+executable that contains the standard library, which then performs the system
+call for us. Also notice that the standard library provides global variables
+like \texttt{errno} which get mutated by system calls to contain special error
+values. These are all defined in \texttt{errno.h} to have unique meanings --
+telling the application what kind of error occured.
+
+\end{document}