completed lec 20,21,22 -- still need lec 23
[kspaans/CS350] / lec05-0519.tex
1 \documentclass{article}
2 \usepackage{fullpage}
3 \usepackage{amsmath}
4 \author{Kyle Spaans}
5 \date{May 15, 2009}
6 \title{Operating Systems Lecture Notes}
7 \begin{document}
8 \maketitle
9
10 \section*{Lecture 5 -- Interrupts and Locks}
11 We are reminded that the test-compile system is online, and that we should
12 submit assignments early and often.
13
14 \subsection*{Bounded Buffer}
15 We can use two semaphores to enforce both a lower and upper bound in the amount
16 of items in, see code in course notes.
17
18 \subsection*{Turning Interrupts On and Off}
19 In looking again at the implementation of \texttt{P()}, we notice that it calls
20 \texttt{thread\_sleep()} from inside of it's critical section, interrupts are
21 turned off. Does this mean that \texttt{thread\_sleep()} will turn them back
22 on? No, in fact the implemtation asserts that interrupts be turned off inside
23 of \texttt{thread\_sleep()}. Think of it this way: interrupts will be turned 
24 off during the entire process of the context switch (naturally). Therefore they
25 will be turned back on when the thread is selected to run again, and execution
26 pops it way down through the stack frames. For example, if another thread that
27 gets context switched to was put to sleep from \texttt{thread\_sleep()} then
28 it will eventually turn interrupts back on after continuing from the return
29 from \texttt{thread\_sleep()}.
30
31 Note that \texttt{thread\_wakeup()} will wakeup every thread
32 if there is more than one thread sleeping on a particular address. Also
33 remember that \texttt{thread\_wakeup()} will not cause a context switch, it
34 only moves thread to the ready queue, out of the sleeping queue. It is
35 non-blocking.
36
37 \subsection*{Implementing Locks}
38 It should not be very hard to implement them, we just need to make sure that
39 we've got them correct, since they will be used everywhere in the rest of
40 \emph{OS161}. Locks are less general than semaphores, but has some handy
41 features. Locks enforce that only the thread that acquired the lock can release
42 it.
43
44 \subsection*{Condition Variables}
45 Designed to be used inside of a critical section, it is always associated with
46 an acquired lock. CV's have three main functions: \texttt{cv\_wait()} which is
47 like \texttt{P()}, \texttt{cv\_signal()} which is like \texttt{V()}, and
48 \texttt{cv\_broadcast()} which is also like \texttt{V()} but will wakeup all
49 threads that are sleeping on that CV. \texttt{Cv\_wait()} is interesting
50 because it takes a CV and a lock, and releases the lock, giving another thread
51 a chance to use it. It will also reacquire the lock before returning to the
52 calling thread. We like CVs because they allow us to sleep on arbitrary
53 conditions, rather than just an address. Also, a CV can be signalled, but if
54 there are no waiting threads, then nothing will happen.
55
56 \subsection*{Introduction to Monitors}
57 The idea of CVs come from Monitors, which are a programming language contruct.
58 This means that they have to be supported by the compiler. We can however
59 emulate their behaviour with careful use of locks and condition variables. This
60 will pay off later, reducing the likelyhood that we will encounter concurrency
61 bugs in later assignments.
62
63 \end{document}