lecture 6 notes
authorKyle Spaans <kspaans@student.math.uwaterloo.ca>
Sun, 24 May 2009 12:22:02 +0000 (08:22 -0400)
committerKyle Spaans <kspaans@student.math.uwaterloo.ca>
Sun, 24 May 2009 12:22:02 +0000 (08:22 -0400)
lec06-0521.tex [new file with mode: 0644]

diff --git a/lec06-0521.tex b/lec06-0521.tex
new file mode 100644 (file)
index 0000000..94f7d78
--- /dev/null
@@ -0,0 +1,37 @@
+\documentclass{article}
+\usepackage{fullpage}
+\usepackage{amsmath}
+\author{Kyle Spaans}
+\date{May 21, 2009}
+\title{Operating Systems Lecture Notes}
+\begin{document}
+\maketitle
+
+\section*{Lecture 6 -- Deadlocks}
+In assignment 1, \texttt{curthread} will come in handy for implementing locks
+and CV's. Remember that locks are not supposed to like it if someone releases
+a lock they don't own, or tries to grab a lock twice.
+
+\subsection*{\emph{OS161} Primer}
+Prof Salem put an
+\emph{OS161} primer online to give us some more source code hints, and C
+programming hints. Note that the kernel has it's own C standard library
+because some stdlib functions are defined in terms of system calls that
+we haven't implemented yet! Some functions haven't changed (\texttt{strcmp()})
+but easy examples of ones that have are those that allocate and free memory or
+print to the screen. Some variables are marked as volatile to make sure that
+they compiler will not optimize away their use. The value of the variable
+could change at any time due to concurrent access, so we want to make sure that
+it's value is directly accessed from memory every time our program uses it,
+rather than let the compiler stealthily cache it's value.
+
+\subsection*{Deadlocks}
+When two or more threads mutually block each other, we have deadlock. None of
+the threads can go anywhere, and they will never break out of this loop
+either. We should be able to identify deadlock given a thread and resource
+graph. If the graph has cycles, this suggests that there is a deadlock, but it
+is not sufficient evidence! We can, even though it's slow, detect and end
+deadlocks, but a better idea is to try and prevent them with smart resource
+allocation policies.
+
+\end{document}