ics 332 (week 7) - synchronization: race conditions

what is the goal of thread synchronization?

- to make sure threads don't step on each other's toes in RAM to ensure program correctness

what is false concurrency?

- illusion of concurrency (because time quanta short)

- created by an OS using context-switching to alternate between processes/threads on a single core

what is true concurrency?

- when multiple threads actually run simultaneously on multiple processor cores

why shouldn't a programmer need to care if their program will use true or false concurrency?

- concurrent program should work correctly on any system & OS handles the transparency through CPU virtualization

how does the type of concurrency affect a multi-threaded program's interactivity?

- multi-threaded program will reach higher interactivity with both true AND false concurrency

how does the type of concurrency affect a multi-threaded program's performance?

- multi-threaded program will reach higher performance only with true concurrency (on multiple cores)

besides multiple CPU cores, what is another example of concurrency between hardware resources?

- concurrency between CPU and disk

what is the classic "pitfall" when programmers first try to use multiple threads?

- thinking that simply adding more threads to a task (like incrementing a counter) will automatically make it faster and work correctly

what is a race condition?

- concurrency bug

- when program's outcome depends on the unpredictable timing or order of execution of multiple threads/processes

what is a lost update?

- type of race condition concurrency bug

- when multiple threads/processes concurrently access & modify the same data --> overwrites which causes lost data

- typically happens in a shared system

what happens when multiple threads increment a shared counter without synchronization?

- race condition occurs

- final count will be incorrect & unpredictable because increments can be lost

why are race conditions particularly difficult to debug?

- non-deterministic (bug might not appear during testing but can suddenly occur for users, making it hard to reproduce)

what is a critical section?

- section(s) of code where only one thread can execute at a time (preventing threads from "stepping on each's toes")

what is the common misconception about what a critical section protects?

- it protects a variable (incorrect!)

- BUT it protects sections of code that access shared variables

what is the key principle for designing good critical sections?

- make short as possible (in execution time)

- use different locks for different variables to maximize concurrency

what are the three requirements for a critical section?

1. mutual exclusion: only one thread in the section at a time

2. progress: thread wanting to enter will eventually get in

3. bounded waiting: a waiting thread won't be starved indefinitely

why must preemptive kernels also worry about race conditions?

- context switch can happen during a system call while the kernel is updating shared data structures --> leading to kernel-level lost updates

what is the modern hardware solution that enables the implementation of locks?

- atomic instructions (CPU instructions that execute completely without being interrupted)

what is a lock and its two fundamental operations?

- synchronization data types that ensures only one thread can access a shared resource at a time, preventing race conditions

- has two states (taken/not taken)

1. acquire() or lock()

2. release() or unlock()

what is spinlock? advantages? disadvantages?

- thread actively waits in a loop ("spins") for a lock, consuming CPU

- advantage: very low overhead --> thread enters the critical section immediately

- disadvantages: won't know how long we spin (when is that lock coming?) —> wastes CPU cycles, power, and generates heat if the critical section is long, as the waiting thread loops continuously

what is blocking lock? advantages? disadvantages?

- thread is put to sleep by the OS and wakes up when key is available, freeing the CPU (wakes CPU up later)

- advantage: wastes zero CPU cycles --> waiting thread is put to sleep (ideal for long waits)

- disadvantages: high overhead --> cost of OS putting the thread to sleep and then waking it up again

when should you use a spinlock vs blocking lock?

- spinlock: very short critical sections

- blocking lock: long critical sections

what problem does Java's synchronized keyword solve?

- prevents the common bug of forgetting to call unlock(), as it automatically handles locking and unlocking

what is an adaptive lock?

- smart lock that tries to be a spinlock first (spins briefly) & if it doesn't get the lock quickly --> becomes a blocking lock