499 lines
22 KiB
TeX
499 lines
22 KiB
TeX
\documentclass[12pt,a4paper]{article}
|
||
|
||
\usepackage[utf8]{inputenc}
|
||
\usepackage[T1]{fontenc}
|
||
\usepackage[margin=2.5cm]{geometry}
|
||
\usepackage{listings}
|
||
\usepackage{xcolor}
|
||
\usepackage{hyperref}
|
||
\usepackage{parskip}
|
||
\usepackage{booktabs}
|
||
\usepackage{array}
|
||
\usepackage{titlesec}
|
||
\usepackage{fancyhdr}
|
||
\usepackage{amsmath}
|
||
\usepackage{enumitem}
|
||
|
||
% ── Page style ──────────────────────────────────────────────────────────────
|
||
\setlength{\headheight}{14.5pt}
|
||
\pagestyle{fancy}
|
||
\fancyhf{}
|
||
\rhead{Advanced Programming – Assignment 9}
|
||
\lhead{Faraz Ardeh}
|
||
\cfoot{\thepage}
|
||
|
||
% ── Section formatting ───────────────────────────────────────────────────────
|
||
\titleformat{\section}{\large\bfseries}{Question \thesection.}{0.6em}{}
|
||
\titleformat{\subsection}{\normalsize\bfseries}{}{0em}{}
|
||
|
||
% ── Java code style ─────────────────────────────────────────────────────────
|
||
\definecolor{javakw}{rgb}{0.13,0.13,0.60}
|
||
\definecolor{javastr}{rgb}{0.63,0.13,0.13}
|
||
\definecolor{javacmt}{rgb}{0.38,0.38,0.38}
|
||
\definecolor{codebg}{rgb}{0.97,0.97,0.97}
|
||
\definecolor{codefr}{rgb}{0.82,0.82,0.82}
|
||
|
||
\lstdefinestyle{java}{
|
||
language=Java,
|
||
basicstyle=\ttfamily\small,
|
||
keywordstyle=\color{javakw}\bfseries,
|
||
stringstyle=\color{javastr},
|
||
commentstyle=\color{javacmt}\itshape,
|
||
numberstyle=\tiny\color{gray},
|
||
numbers=left,
|
||
stepnumber=1,
|
||
numbersep=8pt,
|
||
backgroundcolor=\color{codebg},
|
||
frame=single,
|
||
rulecolor=\color{codefr},
|
||
breaklines=true,
|
||
breakatwhitespace=false,
|
||
showstringspaces=false,
|
||
tabsize=4,
|
||
captionpos=b,
|
||
}
|
||
|
||
\lstset{style=java}
|
||
|
||
% ── Inline code ─────────────────────────────────────────────────────────────
|
||
\newcommand{\code}[1]{\texttt{\small #1}}
|
||
|
||
% ────────────────────────────────────────────────────────────────────────────
|
||
\begin{document}
|
||
|
||
% ── Title page ───────────────────────────────────────────────────────────────
|
||
\begin{titlepage}
|
||
\centering
|
||
\vspace*{3cm}
|
||
{\Huge\bfseries Advanced Multithreading\par}
|
||
\vspace{0.8cm}
|
||
{\large Assignment 9 – Theoretical Questions\par}
|
||
\vspace{0.4cm}
|
||
{\large Advanced Programming (AP)\par}
|
||
\vspace{2cm}
|
||
\rule{0.6\linewidth}{0.5pt}\\[0.4cm]
|
||
{\large\bfseries Faraz Ardeh\par}
|
||
\vspace{0.3cm}
|
||
{\normalsize fa.ardeh@gmail.com\par}
|
||
\vspace{0.6cm}
|
||
{\normalsize Shahid Beheshti University\par}
|
||
\vspace{0.3cm}
|
||
{\normalsize June 2026\par}
|
||
\vfill
|
||
\end{titlepage}
|
||
|
||
\tableofcontents
|
||
\newpage
|
||
|
||
% ════════════════════════════════════════════════════════════════════════════
|
||
\section{What Are Atomic Variables?}
|
||
% ════════════════════════════════════════════════════════════════════════════
|
||
|
||
An \textbf{atomic variable} is a variable whose read-modify-write operations are
|
||
executed as a single, indivisible step -- no other thread can observe an
|
||
intermediate state during the operation.
|
||
|
||
\subsection{How they differ from ordinary variables}
|
||
|
||
With a normal variable, the innocent-looking increment \code{i++} is actually
|
||
\emph{three} separate CPU instructions:
|
||
|
||
\begin{enumerate}[leftmargin=2em]
|
||
\item \textbf{Read} the current value of \code{i} into a register.
|
||
\item \textbf{Add 1} to that register value.
|
||
\item \textbf{Write} the result back to \code{i}.
|
||
\end{enumerate}
|
||
|
||
If two threads execute \code{i++} concurrently, both may read the same value,
|
||
both add 1, and both write back the same result -- one increment is silently
|
||
lost.
|
||
This is a \emph{race condition}.
|
||
|
||
An atomic variable uses a hardware-level instruction called
|
||
\textbf{Compare-And-Swap (CAS)}, which reads, compares, and writes in a single
|
||
CPU operation that cannot be interrupted.
|
||
If another thread changed the value in between, the CAS fails and the operation
|
||
retries -- but no update is ever lost.
|
||
|
||
\subsection{Key difference summary}
|
||
|
||
\begin{center}
|
||
\begin{tabular}{>{\bfseries}lll}
|
||
\toprule
|
||
Property & Ordinary variable & Atomic variable \\
|
||
\midrule
|
||
Thread-safe reads/writes & No & Yes \\
|
||
Compound operations (e.g.\ \code{i++}) & Not atomic & Atomic (CAS) \\
|
||
Requires explicit lock & Yes & No \\
|
||
Performance under low contention & Faster & Comparable \\
|
||
\bottomrule
|
||
\end{tabular}
|
||
\end{center}
|
||
|
||
% ════════════════════════════════════════════════════════════════════════════
|
||
\section{Classes from \code{java.util.concurrent.atomic}}
|
||
% ════════════════════════════════════════════════════════════════════════════
|
||
|
||
The \code{java.util.concurrent.atomic} package provides lock-free, thread-safe
|
||
operations for a range of data types.
|
||
Four commonly used classes are listed below.
|
||
|
||
\begin{center}
|
||
\begin{tabular}{>{\bfseries}ll}
|
||
\toprule
|
||
Class & What it wraps \\
|
||
\midrule
|
||
\code{AtomicInteger} & A single \code{int} value \\
|
||
\code{AtomicLong} & A single \code{long} value \\
|
||
\code{AtomicBoolean} & A single \code{boolean} flag \\
|
||
\code{AtomicReference<V>} & A reference to any object of type \code{V} \\
|
||
\bottomrule
|
||
\end{tabular}
|
||
\end{center}
|
||
|
||
\subsection{Typical use case -- \code{AtomicInteger} as a shared request counter}
|
||
|
||
Imagine a web server where many threads handle HTTP requests simultaneously.
|
||
All of them must increment a shared request counter.
|
||
Using \code{AtomicInteger} avoids a \code{synchronized} block while still
|
||
guaranteeing that every request is counted exactly once:
|
||
|
||
\begin{lstlisting}[caption={Shared request counter with AtomicInteger}]
|
||
import java.util.concurrent.atomic.AtomicInteger;
|
||
|
||
public class RequestCounter {
|
||
private final AtomicInteger count = new AtomicInteger(0);
|
||
|
||
public void handleRequest() {
|
||
int id = count.incrementAndGet(); // atomic: no lock needed
|
||
System.out.println("Handling request #" + id);
|
||
}
|
||
|
||
public int getTotal() {
|
||
return count.get();
|
||
}
|
||
}
|
||
\end{lstlisting}
|
||
|
||
Because \code{incrementAndGet()} is a single atomic CAS instruction, hundreds
|
||
of threads can call it simultaneously without any of them ever seeing a stale
|
||
or lost count.
|
||
|
||
% ════════════════════════════════════════════════════════════════════════════
|
||
\section{Locks vs.\ Atomic Variables}
|
||
% ════════════════════════════════════════════════════════════════════════════
|
||
|
||
Both locks and atomic variables protect shared data from concurrent access, but
|
||
they are suited to different scenarios.
|
||
|
||
\subsection{When a lock is the better choice}
|
||
|
||
\begin{itemize}[leftmargin=2em]
|
||
\item \textbf{Multiple variables must stay consistent together.}
|
||
Atomic variables protect exactly one value at a time.
|
||
If you need to update an account's \code{balance} and \code{lastModified}
|
||
timestamp as one unit, only a lock can guard both fields atomically.
|
||
|
||
\item \textbf{Complex conditions and waiting.}
|
||
Locks support \code{Condition} objects (\code{await}/\code{signal}),
|
||
letting a thread block until some business invariant is satisfied
|
||
(e.g.\ ``wait until the queue is non-empty'').
|
||
Atomic variables provide no such mechanism.
|
||
|
||
\item \textbf{Long critical sections.}
|
||
If the guarded work is more than a single read-modify-write (e.g.\
|
||
several method calls or I/O), a lock is the natural fit.
|
||
CAS-based retry loops become expensive when the critical section is
|
||
long, because failed retries waste CPU cycles.
|
||
\end{itemize}
|
||
|
||
\subsection{When an atomic variable is the better choice}
|
||
|
||
\begin{itemize}[leftmargin=2em]
|
||
\item \textbf{Single-variable, simple operations.}
|
||
Counters, flags, and version numbers that are updated with one CAS
|
||
have lower overhead than acquiring and releasing a lock.
|
||
|
||
\item \textbf{High-read, low-write scenarios.}
|
||
\code{AtomicReference} allows a single writer to publish a new
|
||
immutable snapshot while many readers access the current reference
|
||
without any blocking.
|
||
|
||
\item \textbf{Non-blocking algorithms.}
|
||
Lock-free data structures (e.g.\ \code{ConcurrentLinkedQueue}) use
|
||
CAS to guarantee progress even if one thread is delayed, whereas a
|
||
lock-based structure can stall all other threads if the lock holder
|
||
is descheduled.
|
||
\end{itemize}
|
||
|
||
\begin{center}
|
||
\begin{tabular}{>{\bfseries}lll}
|
||
\toprule
|
||
Situation & Better choice & Reason \\
|
||
\midrule
|
||
Single counter / flag & Atomic variable & Low overhead, no blocking \\
|
||
Multiple fields as one unit & Lock & Atomicity across several variables \\
|
||
Conditional waiting & Lock & \code{Condition.await()} / \code{signal()} \\
|
||
Long critical section & Lock & CAS retries too costly \\
|
||
Non-blocking read-heavy & Atomic variable & Readers never block \\
|
||
\bottomrule
|
||
\end{tabular}
|
||
\end{center}
|
||
|
||
% ════════════════════════════════════════════════════════════════════════════
|
||
\section{Correct but Slow -- Scalability Limits Under High Contention}
|
||
% ════════════════════════════════════════════════════════════════════════════
|
||
|
||
A program can be completely free of race conditions and still perform poorly
|
||
when many threads compete for the same resources.
|
||
Correctness and scalability are independent properties.
|
||
|
||
\subsection{Why this happens}
|
||
|
||
When every thread must pass through the same lock, threads queue up waiting
|
||
even if they could logically run in parallel.
|
||
Adding more CPU cores does not help -- the bottleneck is the shared resource,
|
||
not raw compute power.
|
||
This matches \textbf{Amdahl's Law}: total speedup is bounded by the fraction
|
||
of work that \emph{cannot} be parallelised.
|
||
|
||
\subsection{Three concurrency factors that limit scalability}
|
||
|
||
\begin{enumerate}[leftmargin=2em,label=\textbf{\arabic*.}]
|
||
|
||
\item \textbf{Lock contention.}
|
||
A coarse-grained lock (one lock protecting many accounts, for example)
|
||
serialises all threads even when they are working on completely
|
||
independent data.
|
||
The more threads, the longer each one waits.
|
||
The solution is to use finer-grained locking -- one lock per account
|
||
instead of one global lock -- so threads that are not sharing data can
|
||
proceed concurrently.
|
||
|
||
\item \textbf{False sharing (cache-line contention).}
|
||
Modern CPUs cache memory in 64-byte \emph{cache lines}.
|
||
If two threads update logically unrelated variables that happen to
|
||
reside on the same cache line, each write by one thread invalidates
|
||
the other core's cached copy.
|
||
The hardware constantly transfers the cache line between cores -- a
|
||
hidden performance cost that grows with thread count even though there
|
||
is no logical data sharing between the threads.
|
||
|
||
\item \textbf{Memory bandwidth saturation.}
|
||
With many threads all reading and writing shared state, the memory bus
|
||
becomes a bottleneck.
|
||
Once the bus is saturated, adding more threads only increases waiting
|
||
time -- each thread must wait longer for its memory access to be
|
||
serviced.
|
||
Throughput plateaus or even decreases despite the increase in CPU
|
||
utilisation.
|
||
|
||
\end{enumerate}
|
||
|
||
% ════════════════════════════════════════════════════════════════════════════
|
||
\section{Why More Threads Do Not Always Improve Performance}
|
||
% ════════════════════════════════════════════════════════════════════════════
|
||
|
||
Intuitively, more threads should mean more parallelism and faster execution.
|
||
In practice, beyond a certain point additional threads hurt rather than help.
|
||
|
||
\subsection{Context switching}
|
||
|
||
When the number of threads exceeds the number of CPU cores, the operating
|
||
system must \emph{time-slice}: it saves the full register state of one thread
|
||
and loads the state of another many times per second.
|
||
Each switch has a non-trivial cost (typically a few microseconds).
|
||
With hundreds of threads competing for a small number of cores, the CPU can
|
||
spend a significant fraction of its time doing bookkeeping instead of useful
|
||
work.
|
||
|
||
\subsection{Lock contention}
|
||
|
||
More threads means more threads competing for the same lock simultaneously.
|
||
Each additional thread increases the average queue length at every lock, so
|
||
threads spend proportionally more time \emph{blocked} and less time running.
|
||
In extreme cases, throughput actually decreases because the contention overhead
|
||
outweighs any benefit from concurrency.
|
||
|
||
\subsection{Cache coherence}
|
||
|
||
Every CPU core maintains its own L1/L2 cache.
|
||
When one core writes to a shared variable, all other cores that cached that
|
||
value must \emph{invalidate} their copy (the MESI protocol).
|
||
With many threads spread across many cores, this cache-invalidation ``chatter''
|
||
becomes expensive: cores stall waiting for the authoritative copy to arrive
|
||
from another core's cache or from main memory.
|
||
|
||
\subsection{Synchronization overhead}
|
||
|
||
Every \code{lock()}/\code{unlock()} pair, every \code{synchronized} block, and
|
||
every \code{volatile} write inserts a \emph{memory fence} instruction.
|
||
Memory fences force the CPU to flush its store buffers and ensure all prior
|
||
writes are visible to other cores before proceeding.
|
||
The more threads, the more synchronisation events per unit of time, and the
|
||
more time spent on coordination rather than computation.
|
||
|
||
\subsection{Summary}
|
||
|
||
\begin{center}
|
||
\begin{tabular}{>{\bfseries}ll}
|
||
\toprule
|
||
Factor & Effect \\
|
||
\midrule
|
||
Context switching & CPU wastes time saving/restoring thread state \\
|
||
Lock contention & Threads queue up; throughput flattens or drops \\
|
||
Cache coherence & Cores stall waiting for invalidated cache lines \\
|
||
Sync overhead & Memory fences cost cycles per lock/volatile operation \\
|
||
\bottomrule
|
||
\end{tabular}
|
||
\end{center}
|
||
|
||
% ════════════════════════════════════════════════════════════════════════════
|
||
\section{Why Deadlocks Appear in Production but Not During Testing}
|
||
% ════════════════════════════════════════════════════════════════════════════
|
||
|
||
\subsection{A thread-scheduling perspective}
|
||
|
||
A deadlock requires a very specific simultaneous state: Thread~A holds
|
||
lock~1 and waits for lock~2, while Thread~B holds lock~2 and waits for lock~1
|
||
-- at the \emph{same instant}.
|
||
This is called a \emph{circular wait}.
|
||
|
||
In a typical test environment:
|
||
\begin{itemize}[leftmargin=2em]
|
||
\item The workload is small (few threads, few iterations).
|
||
\item The JVM is freshly started with warm-up behaviour.
|
||
\item The OS scheduler tends to run the same thread continuously for short
|
||
tasks, so the critical interleaving rarely occurs.
|
||
\end{itemize}
|
||
|
||
In production:
|
||
\begin{itemize}[leftmargin=2em]
|
||
\item There are many more threads running concurrently.
|
||
\item Higher load means more context switches per second.
|
||
\item Different hardware (more cores, different cache sizes) produces
|
||
different scheduling patterns.
|
||
\item The combination of load, hardware, and OS scheduler eventually
|
||
\emph{will} hit the exact timing that triggers the circular wait,
|
||
making it a statistical certainty over hours of operation.
|
||
\end{itemize}
|
||
|
||
\subsection{Two strategies to expose deadlocks during testing}
|
||
|
||
\begin{enumerate}[leftmargin=2em,label=\textbf{\arabic*.}]
|
||
|
||
\item \textbf{Stress testing with a start-gun latch.}
|
||
Create many more threads than CPU cores (e.g.\ 50--100 threads for
|
||
a 4-core machine), use a \code{CountDownLatch} to hold them all back,
|
||
then release them simultaneously with a single \code{countDown()}.
|
||
Every thread starts at the same instant, maximising contention and
|
||
forcing the scheduler to interleave lock acquisitions in ways that
|
||
almost never happen under light load.
|
||
A deadlock that requires simultaneous lock attempts becomes statistically
|
||
likely within seconds.
|
||
This is exactly the technique used in the provided
|
||
\code{BankAccountTransferDeadlockTest}:
|
||
|
||
\begin{lstlisting}[caption={Stress test with a start-gun latch}]
|
||
CountDownLatch startGun = new CountDownLatch(1);
|
||
// ... submit 50 000 tasks that each await(startGun) before transferring
|
||
startGun.countDown(); // all tasks released at once
|
||
\end{lstlisting}
|
||
|
||
\item \textbf{Inject random delays between lock acquisitions.}
|
||
Insert a short \code{Thread.sleep(randomMillis)} between acquiring
|
||
the first lock and trying to acquire the second.
|
||
This \emph{widens} the window during which another thread can step in,
|
||
acquire its own first lock (which is the second lock of the first
|
||
thread), and then attempt the lock that the first thread holds -- the
|
||
exact condition for a circular wait.
|
||
Even a 1--5 ms random delay dramatically increases the probability
|
||
of hitting the deadlock without requiring a huge thread count.
|
||
This technique is sometimes called \emph{sleep injection} or
|
||
\emph{timing perturbation}.
|
||
|
||
\end{enumerate}
|
||
|
||
% ════════════════════════════════════════════════════════════════════════════
|
||
\section*{Bonus: \code{AtomicInteger} vs.\ Plain \code{int} Race Condition}
|
||
\addcontentsline{toc}{section}{Bonus: AtomicInteger vs.\ Plain int Race Condition}
|
||
% ════════════════════════════════════════════════════════════════════════════
|
||
|
||
The program below creates 100 threads, each incrementing both a plain
|
||
\code{int} and an \code{AtomicInteger} 1\,000 times.
|
||
The expected final value is $100 \times 1000 = 100\,000$.
|
||
|
||
\begin{lstlisting}[caption={RaceConditionDemo.java}]
|
||
import java.util.concurrent.atomic.AtomicInteger;
|
||
|
||
public class RaceConditionDemo {
|
||
|
||
static int unsafeCounter = 0;
|
||
static AtomicInteger safeCounter = new AtomicInteger(0);
|
||
|
||
public static void main(String[] args) throws InterruptedException {
|
||
|
||
int threadCount = 100;
|
||
int incrementsPerThread = 1000;
|
||
|
||
Thread[] threads = new Thread[threadCount];
|
||
|
||
for (int i = 0; i < threadCount; i++) {
|
||
threads[i] = new Thread(() -> {
|
||
for (int j = 0; j < incrementsPerThread; j++) {
|
||
unsafeCounter++; // NOT atomic -- race condition!
|
||
safeCounter.incrementAndGet(); // atomic -- always correct
|
||
}
|
||
});
|
||
}
|
||
|
||
for (Thread t : threads) t.start();
|
||
for (Thread t : threads) t.join();
|
||
|
||
int expected = threadCount * incrementsPerThread;
|
||
|
||
System.out.println("Expected : " + expected);
|
||
System.out.println("Unsafe int: " + unsafeCounter
|
||
+ (unsafeCounter == expected ? " (correct)" : " <-- LOST UPDATES!"));
|
||
System.out.println("AtomicInt : " + safeCounter.get()
|
||
+ (safeCounter.get() == expected ? " (correct)" : " <-- wrong!"));
|
||
}
|
||
}
|
||
\end{lstlisting}
|
||
|
||
\subsection*{Sample output}
|
||
|
||
\begin{lstlisting}[language={},numbers=none,backgroundcolor=\color{codebg}]
|
||
Expected : 100000
|
||
Unsafe int: 94371 <-- LOST UPDATES!
|
||
AtomicInt : 100000 (correct)
|
||
\end{lstlisting}
|
||
|
||
\subsection*{Why the unsafe counter is wrong}
|
||
|
||
\code{unsafeCounter++} compiles to three bytecode instructions: \code{getfield},
|
||
\code{iadd}, \code{putfield}.
|
||
Between any two of these instructions the thread scheduler can switch to
|
||
another thread.
|
||
If two threads both read the same value (say 5\,000), both add 1, and both
|
||
write back 5\,001, one increment vanishes entirely.
|
||
Under 100 threads this happens thousands of times, so the final value is
|
||
typically several thousand less than 100\,000.
|
||
|
||
\code{AtomicInteger.incrementAndGet()} maps to a single \code{lock xadd} CPU
|
||
instruction (on x86) that is guaranteed to be indivisible.
|
||
No thread can read an intermediate state; every increment is counted
|
||
exactly once, and the result is always 100\,000.
|
||
|
||
% ── Footer note ──────────────────────────────────────────────────────────────
|
||
\vfill
|
||
\begin{center}
|
||
\small\color{gray}
|
||
Advanced Programming – Assignment 9 \quad|\quad
|
||
Faraz Ardeh \quad|\quad
|
||
Shahid Beheshti University \quad|\quad
|
||
June 2026
|
||
\end{center}
|
||
|
||
\end{document}
|