added load balancing to lec 18 notes
[kspaans/CS350] / lec06-0521.tex
1 \documentclass{article}
2 \usepackage{fullpage}
3 \usepackage{amsmath}
4 \author{Kyle Spaans}
5 \date{May 21, 2009}
6 \title{Operating Systems Lecture Notes}
7 \begin{document}
8 \maketitle
9
10 \section*{Lecture 6 -- Deadlocks}
11 In assignment 1, \texttt{curthread} will come in handy for implementing locks
12 and CV's. Remember that locks are not supposed to like it if someone releases
13 a lock they don't own, or tries to grab a lock twice.
14
15 \subsection*{\emph{OS161} Primer}
16 Prof Salem put an
17 \emph{OS161} primer online to give us some more source code hints, and C
18 programming hints. Note that the kernel has it's own C standard library
19 because some stdlib functions are defined in terms of system calls that
20 we haven't implemented yet! Some functions haven't changed (\texttt{strcmp()})
21 but easy examples of ones that have are those that allocate and free memory or
22 print to the screen. Some variables are marked as volatile to make sure that
23 they compiler will not optimize away their use. The value of the variable
24 could change at any time due to concurrent access, so we want to make sure that
25 it's value is directly accessed from memory every time our program uses it,
26 rather than let the compiler stealthily cache it's value.
27
28 \subsection*{Deadlocks}
29 When two or more threads mutually block each other, we have deadlock. None of
30 the threads can go anywhere, and they will never break out of this loop
31 either. We should be able to identify deadlock given a thread and resource
32 graph. If the graph has cycles, this suggests that there is a deadlock, but it
33 is not sufficient evidence! We can, even though it's slow, detect and end
34 deadlocks, but a better idea is to try and prevent them with smart resource
35 allocation policies.
36
37 \end{document}