Assignment 9 – Theoretical Questions

2026-06-25 13:22:14 +03:30
parent e699d71f20
commit 38fdf65a72
2 changed files with 0 additions and 498 deletions
@@ -1,498 +0,0 @@
 \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}