Skip to main content\(\newcommand{\N}{\mathbb N} \newcommand{\Z}{\mathbb Z} \newcommand{\Q}{\mathbb Q} \newcommand{\R}{\mathbb R}
\newcommand{\lt}{<}
\newcommand{\gt}{>}
\newcommand{\amp}{&}
\definecolor{fillinmathshade}{gray}{0.9}
\newcommand{\fillinmath}[1]{\mathchoice{\colorbox{fillinmathshade}{$\displaystyle \phantom{\,#1\,}$}}{\colorbox{fillinmathshade}{$\textstyle \phantom{\,#1\,}$}}{\colorbox{fillinmathshade}{$\scriptstyle \phantom{\,#1\,}$}}{\colorbox{fillinmathshade}{$\scriptscriptstyle\phantom{\,#1\,}$}}}
\)
Section 4.3 Locks
This section covers
book chapter 28, on the topic of locks. Start by reading sections 28.1, 28.2, 28.3.
Practice 4.3.1.
Which of the following are possible states for a lock variable?
Read section 28.4 about the criteria to use when evaluating lock implementations.
Practice 4.3.2.
Which of the following are objectives of a good lock implementation?
Ensuring that if there are timing-related errors in user code, they will be notified at compile time.
-
Ensuring that two threads cannot execute code within a lock-protected region at the same time.
-
Ensuring that all threads contending for a lock-protected region of code get a reasonable chance to run that code at some point.
-
Allowing for optimal use of multiple CPUs.
While this is generally a good goal for an OS, it is not directly related to lock implementations.
Adding little overhead to the runtime of the program.
-
Read section 28.5, about the use of interrupt-disabling to provide mutual exclusion.
Practice 4.3.3.
What are the disadvantages of doing locking via disabling interrupts?
It is simple to implement.
Thatβs an advantage, not a disadvantage.
We are allowing user-controlled threads to perform such a priviledged operation as disabling interrupts. This is too much trust put on the user.
-
It wonβt work reasonably with multiple CPUs.
-
Turning off interrupts for long periods of time can lead in lost interrupts and missed behavior (e.g. a disk read getting lost).
-
Read section 28.6, about a first attempt at locks using a simple flag load-store.
Practice 4.3.4.
Figure 28.2 describes the one of the problems with the simple flag value-setting as a locking mechanism. What problem does it demonstrate?
Multiple threads might all be stuck waiting for the flag to clear but noone being able to do so.
-
It can happen the multiple threads enter the critical section at the same time.
-
A thread might spin-wait and waste many cycles doing nothing.
While this is a problem with the overall approach, that is not the problem that Figure 28.2 demonstrates.
Read section 28.7, about the test-and-set instruction. Make sure you understand why the code in Figure 28.3 works.
Practice 4.3.5.
Practice 4.3.6.
True or False: The test-and-set approach solves the problem of having the thread spin-wait for its turn.
True.
It doesnβt solve that problem, but it does solve the problem of actually achieving mutual exclusion.
False.
It doesnβt solve that problem, but it does solve the problem of actually achieving mutual exclusion.
Read section 28.8, about evaluating spin locks.
Practice 4.3.7.
Read section 28.9 about the compare-and-swap primitive.
Skip sections 28.10 and 28.11.
Read sections 28.12 and 28.13, about one alternative to spinning.
Practice 4.3.8.
Read section 28.14 about using a queue and sleeping infrastructure.
The remaining sections are optional.
You have attempted
of
activities on this page.