Computer-Fundamentals/archive/os/concurrency.md

Concurrency and Synchronization for Interviews

This guide is meant for software engineers who already write production code and want a deeper, interview-ready mental model of concurrency. The goal is not just to memorize definitions, but to understand what problems concurrency introduces, what tools operating systems and runtimes provide, and how these ideas show up in backend systems and multithreaded applications.

---

1. Why Concurrency Matters

Modern software rarely runs as a single straight-line sequence of instructions. Web servers handle many requests at once, databases coordinate many clients, background workers process jobs in parallel, and operating systems multiplex CPU time across many threads and processes.

Concurrency exists because real systems need at least one of these:

• Responsiveness: one task should not block all others.
• Throughput: multiple units of work should make progress over the same period.
• Resource utilization: idle CPU time or I/O wait should be reduced.
• Structure: independent activities are easier to model as independent execution flows.

The cost is coordination. As soon as two execution flows can interact with shared state, correctness becomes harder.

---

2. Concurrency and Parallelism

Concurrency

Concurrency means multiple tasks are in progress during the same overall time interval. They may not literally run at the same instant. A single CPU core can still execute concurrent work by interleaving threads.

Think of concurrency as dealing with many things at once.

Examples:

• A web server handling many client connections with an event loop.
• A program with a UI thread and a background worker thread.
• An OS scheduling several runnable threads on one core.

Parallelism

Parallelism means multiple tasks are executing at the same instant, usually on different CPU cores or different hardware units.

Think of parallelism as doing many things at once.

Examples:

• A matrix multiplication split across 8 CPU cores.
• A thread pool running several CPU-heavy jobs at the same time.
• GPU kernels operating on many data elements simultaneously.

Concurrency vs Parallelism

They are related but not identical.

• Concurrency is about composition and coordination.
• Parallelism is about simultaneous execution.
• A program can be concurrent without being parallel.
• A parallel program is usually concurrent, because simultaneous work still needs coordination.

flowchart TD
	A[Program has multiple tasks] --> B{One core or many cores?}
	B -->|One core| C[Concurrent via interleaving]
	B -->|Many cores| D[Potentially parallel]
	C --> E[Tasks overlap in time but not at the same instant]
	D --> F[Tasks can run at the same instant]
	E --> G[Still needs synchronization if state is shared]
	F --> G

Interview framing

If asked for the difference, a strong answer is:

Concurrency is a design property where multiple tasks make progress during the same time window. Parallelism is an execution property where multiple tasks run simultaneously. Concurrency is mainly about coordinating independent work; parallelism is mainly about speeding work up with more hardware.

---

3. Synchronization Basics

Synchronization is the coordination of concurrent execution so that shared data stays correct and required ordering relationships are preserved.

When engineers say synchronization, they usually mean one or more of these:

• Mutual exclusion: only one thread enters a critical region at a time.
• Ordering: thread B should not proceed until thread A completes some step.
• Visibility: changes made by one thread should become visible to others at the correct time.
• Coordination: threads should wait, signal, or hand off work safely.

The three main correctness concerns

1. Atomicity

An operation is atomic if it happens as one indivisible unit from the perspective of other threads.

count++ is usually not atomic. It is often:

1. Read count
2. Add 1
3. Write result back

If two threads do that concurrently, one update can be lost.

2. Visibility

Even if one thread writes a new value, another thread may not see it immediately because of CPU caches, compiler reordering, or runtime memory models.

3. Ordering

Operations may be observed in a different order than they appear in code unless synchronization constructs create ordering guarantees.

This is why synchronization is not only about locking. It is also about memory semantics.

---

4. Race Conditions

A race condition occurs when the correctness of a program depends on the relative timing or interleaving of concurrent operations.

Not every race is bad, but most interview discussions mean a harmful data race or logic race.

Simple example

Two threads increment the same shared counter initialized to 0.

Without synchronization:

1. Thread A reads 0
2. Thread B reads 0
3. Thread A writes 1
4. Thread B writes 1

Final value becomes 1 instead of 2.

sequenceDiagram
	participant A as Thread A
	participant M as Shared Counter
	participant B as Thread B

	A->>M: read 0
	B->>M: read 0
	A->>M: write 1
	B->>M: write 1

Data race vs race condition

• A data race usually means two threads access the same memory location concurrently, at least one is a write, and there is no proper synchronization.
• A race condition is broader. The bug comes from timing dependence, even if access is not literally the same variable.

Example of a logic race:

• Thread A checks that a file exists.
• Thread B deletes it.
• Thread A then tries to open it and fails.

How to talk about race conditions in interviews

Do not stop at "two threads update the same variable." Mention the root issue:

• non-atomic read-modify-write,
• missing ordering guarantees,
• unsafely shared mutable state,
• check-then-act or read-then-use races,
• stale reads due to visibility issues.

---

5. The Critical Section Problem

A critical section is a part of code that accesses shared data or shared resources and therefore must not be executed by more than one thread at the same time when doing so would break correctness.

The critical section problem asks: how do we design a protocol so multiple threads can safely share resources?

Classic requirements

An ideal solution satisfies:

1. Mutual exclusion At most one thread is in the critical section at a time.
2. Progress If no thread is in the critical section, the choice of who enters next should not be postponed forever.
3. Bounded waiting A thread waiting to enter should not be postponed indefinitely.

Example

Updating a shared bank account balance, modifying a shared queue, or writing to a shared log buffer are all critical section scenarios.

The main interview point: once you identify shared mutable state, ask whether access must be serialized.

---

6. Mutual Exclusion

Mutual exclusion means ensuring that only one thread or process at a time can execute a critical section.

This is the most basic synchronization guarantee.

Common ways to provide mutual exclusion:

• Locks
• Mutexes
• Binary semaphores
• Monitors
• Atomic instructions used to build higher-level locks

Mutual exclusion solves some problems, but not all. If threads also need to wait for particular conditions, you need coordination mechanisms such as semaphores or condition variables.

---

7. Locks and Synchronization Mechanisms

Synchronization mechanisms are tools that control access to shared state or coordinate thread behavior.

Major categories

• Blocking locks: thread sleeps if it cannot proceed.
• Spinning locks: thread keeps retrying until it can proceed.
• Signaling primitives: thread waits for an event or condition.
• Atomic primitives: hardware-supported indivisible operations.

Design tradeoff

Every synchronization tool trades off some combination of:

• Simplicity
• Latency
• CPU efficiency
• Fairness
• Scalability under contention
• Ease of reasoning

In interviews, strong answers compare mechanisms instead of treating them as equivalent.

---

8. Mutexes

A mutex is a mutual exclusion lock. Only one thread can hold it at a time.

Typical behavior:

1. Thread calls lock()
2. If mutex is free, thread acquires it and enters critical section
3. If mutex is already held, thread blocks or waits
4. Thread eventually calls unlock()

Why mutexes are useful

• Simple mental model
• Good for protecting shared data structures
• Usually implemented efficiently by the OS and runtime

Example

lock(mutex)
balance = balance - amount
unlock(mutex)

Important interview details

• A mutex is ownership-based: the thread that acquires it is usually the one expected to release it.
• Holding a mutex too long hurts throughput.
• Calling blocking I/O while holding a mutex can create latency spikes and deadlock risk.
• Fine-grained locking improves concurrency but increases complexity.
• Coarse-grained locking is simpler but reduces parallelism.

Common backend example

An in-memory cache may protect its hash map with a mutex so concurrent requests do not corrupt internal buckets or linked structures.

---

9. Semaphores

A semaphore is a synchronization primitive represented by a counter plus wait/signal operations.

Typical operations:

• wait() or P(): decrement the counter if possible; otherwise block until it becomes possible.
• signal() or V(): increment the counter and potentially wake a waiting thread.

Semaphores are more general than mutexes.

Intuition

• If the count represents available resources, wait() consumes one resource.
• signal() releases one resource.

Example use cases

• Limit only 10 threads to access a connection pool at once.
• Coordinate producer-consumer queues.
• Gate access to a fixed number of identical resources.

Interview caution

Semaphores are powerful but easy to misuse because they do not encode ownership like mutexes do. A thread can signal a semaphore even if it was not the thread that waited on it.

---

10. Binary Semaphore vs Counting Semaphore

Binary semaphore

A binary semaphore takes values like 0 or 1.

It can be used similarly to a lock:

• 1 means available
• 0 means unavailable

But conceptually it is still a semaphore, not a mutex.

Differences from a mutex:

• Mutexes generally have ownership semantics.
• Binary semaphores are more about signaling and availability than ownership.

Counting semaphore

A counting semaphore can take values greater than 1.

It represents multiple identical resources.

Examples:

• 20 database connections available
• 8 worker slots available
• 100 requests allowed in a bounded in-flight queue

Interview summary

• Use a mutex when exactly one thread should enter a critical section.
• Use a counting semaphore when you want to control access to a pool of N identical resources.
• Use a binary semaphore when you want simple availability or signaling semantics, not necessarily lock ownership.

---

11. Spinlocks

A spinlock is a lock where a thread repeatedly checks until the lock becomes available instead of sleeping.

When spinlocks make sense

• Lock hold time is expected to be extremely short.
• Sleeping and waking a thread would cost more than spinning.
• Code is running in low-level systems contexts such as kernels.
• The waiting thread cannot safely sleep.

When spinlocks are a bad idea

• The critical section may take noticeable time.
• The holder may be preempted.
• CPU cycles are scarce.
• Contention is high.

Tradeoff

Spinlocks reduce context-switch overhead but waste CPU while waiting.

Interview phrasing

A spinlock is good when wait time is shorter than sleep/wake overhead. It is bad under long hold times or high contention because it burns CPU doing no useful work.

---

12. Monitors

A monitor is a higher-level synchronization construct that combines:

• shared data,
• procedures that operate on that data,
• an implicit lock,
• and often condition variables for waiting and signaling.

Only one thread executes inside the monitor at a time.

Why monitors matter

Monitors package data and synchronization together, which makes reasoning easier than manually scattering locks around code.

Languages and runtimes often offer monitor-like behavior through:

• synchronized methods or blocks,
• object monitors,
• condition variables associated with locks.

Interview intuition

A monitor is not just a lock. It is a structured model where the shared state and the rules for accessing it live together.

---

13. Condition Variables

A condition variable allows threads to sleep until some condition becomes true.

This is useful when mutual exclusion alone is not enough.

Example:

• A consumer should wait until the queue is non-empty.
• A producer should wait until the buffer is non-full.

Key pattern

Condition variables are used with a lock.

Typical pattern:

1. Acquire lock
2. While condition is false, wait on condition variable
3. Waiting atomically releases the lock and sleeps
4. When awakened, re-acquire lock and re-check the condition
5. Proceed when the condition is truly satisfied

Why use while, not if

Because:

• spurious wakeups can happen,
• another thread may consume the condition before this thread resumes,
• the condition must be re-verified under the lock.

Example pseudocode

lock(mutex)
while queue.is_empty():
	wait(not_empty, mutex)
item = queue.pop()
unlock(mutex)

Interview point

Condition variables are for waiting on state changes, not for protecting data by themselves. The mutex protects the state; the condition variable coordinates waiting.

---

14. Producer-Consumer Problem

This is a classic synchronization problem.

• Producers generate data and place it into a buffer.
• Consumers remove data from the buffer and process it.

Core challenge

• Producers must not write into a full buffer.
• Consumers must not read from an empty buffer.
• Shared buffer operations must be synchronized.

Common solution

Use:

• a mutex to protect buffer access,
• a not_empty condition,
• a not_full condition.

flowchart LR
	P[Producer] -->|enqueue item| B[Bounded Buffer]
	B -->|dequeue item| C[Consumer]
	P --> N1[Wait if buffer full]
	C --> N2[Wait if buffer empty]

Pseudocode

produce(item):
	lock(mutex)
	while buffer.is_full():
		wait(not_full, mutex)
	buffer.push(item)
	signal(not_empty)
	unlock(mutex)

consume():
	lock(mutex)
	while buffer.is_empty():
		wait(not_empty, mutex)
	item = buffer.pop()
	signal(not_full)
	unlock(mutex)
	return item

Real-world backend analogy

• Producers: API servers enqueue tasks.
• Buffer: message queue or in-memory work queue.
• Consumers: worker threads or worker processes.

Interviewers like this problem because it tests whether you understand both mutual exclusion and condition synchronization.

---

15. Readers-Writers Problem

This problem models a shared resource such as a database record, cache entry, or in-memory configuration.

• Many readers can safely access the resource at the same time.
• Writers require exclusive access.

Goal

Maximize concurrency for readers without allowing reads to overlap with writes.

Variants

• Reader-preference: readers proceed freely, but writers may starve.
• Writer-preference: writers are favored, but readers may wait longer.
• Fair solution: tries to avoid starvation for either side.

Real-world example

Suppose many threads read configuration data from a shared object, but only occasional admin updates modify it.

• A plain mutex works but serializes all readers.
• A read-write lock allows concurrent readers and exclusive writers.

Interview lesson

This problem is about balancing throughput and fairness.

If you mention read-write locks, also mention their downside:

• More overhead than a normal mutex
• Possible writer starvation depending on policy
• Sometimes not worth it if writes are frequent or critical sections are tiny

---

16. Dining Philosophers Problem

This classic problem shows how individually sensible resource acquisition can produce system-wide deadlock.

Setup:

• 5 philosophers sit around a table.
• A fork lies between each pair.
• Each philosopher needs both adjacent forks to eat.

The problem

If every philosopher picks up the left fork first, they may all hold one fork and wait forever for the other.

Why interviewers ask it

It tests whether you can reason about:

• circular wait,
• deadlock,
• resource ordering,
• concurrency design, not just syntax.

flowchart LR
	P1[Philosopher 1] --> F1[Fork 1]
	P2[Philosopher 2] --> F2[Fork 2]
	P3[Philosopher 3] --> F3[Fork 3]
	P4[Philosopher 4] --> F4[Fork 4]
	P5[Philosopher 5] --> F5[Fork 5]
	F1 --> P2
	F2 --> P3
	F3 --> P4
	F4 --> P5
	F5 --> P1

Common solutions

• Impose a global ordering on forks and always pick lower-numbered first.
• Allow at most 4 philosophers to try eating at once.
• Use a waiter/arbitrator to control access.
• Make one philosopher pick up forks in opposite order.

Deeper takeaway

The important concept is not philosophers. It is resource acquisition ordering.

---

17. Deadlocks

A deadlock occurs when a set of threads or processes are permanently blocked because each is waiting for a resource held by another.

Example

• Thread A holds lock 1 and waits for lock 2.
• Thread B holds lock 2 and waits for lock 1.

Neither can proceed.

Deadlock in real systems

• Two services each hold a distributed lock and wait on the other.
• One thread holds a cache lock and calls into code that needs a DB lock, while another thread holds the DB lock and needs the cache lock.
• A transaction waits for rows locked by another transaction, while that transaction waits back on rows from the first.

flowchart LR
	T1[Thread A] -->|waiting for| L2[Lock 2]
	L1[Lock 1] -->|held by| T1
	T2[Thread B] -->|waiting for| L1
	L2 -->|held by| T2

---

18. Necessary Conditions for Deadlock: Coffman Conditions

Four conditions must hold simultaneously for deadlock to be possible.

1. Mutual exclusion At least one resource must be non-shareable.
2. Hold and wait A thread holds at least one resource while waiting for others.
3. No preemption Resources cannot be forcibly taken away; they must be released voluntarily.
4. Circular wait There exists a circular chain of threads, each waiting for a resource held by the next.

Interview insight

To prevent deadlock, you only need to break one of the Coffman conditions. This is the foundation of many prevention strategies.

---

19. Deadlock Prevention, Avoidance, Detection, and Recovery

These are four different strategies. Interviewers often expect you to distinguish them clearly.

Prevention

Design the system so deadlock cannot occur.

Ways to do this:

• Remove hold-and-wait: acquire everything at once.
• Remove circular wait: enforce global lock ordering.
• Remove no-preemption: allow rollback or forced release in some systems.
• Reduce mutual exclusion when possible: use immutable data or lock-free structures.

Tradeoff:

• Often conservative
• Can reduce utilization or concurrency

Avoidance

Make allocation decisions dynamically so the system never enters an unsafe state.

The classic example is Banker's Algorithm.

Key idea:

• Not every currently safe-looking allocation is future-safe.
• The system checks whether granting a request could leave it in a state where some completion order still exists.

Tradeoff:

• Requires knowledge of future maximum demands
• Rare in general-purpose production software
• Important mostly as an interview and OS theory concept

Detection

Allow deadlocks to happen, then detect them.

Examples:

• DBMS lock manager detects wait-for cycles.
• OS or runtime analyzes resource graphs.

Tradeoff:

• Useful when deadlocks are rare
• Requires monitoring and detection overhead

Recovery

Once deadlock is detected, recover by:

• killing a process or transaction,
• rolling back work,
• preempting resources if possible,
• restarting part of the system.

Practical interview answer

In application code, deadlock prevention through lock ordering is the most common strategy. Databases often use detection and recovery because transactions can be rolled back.

---

20. Starvation vs Deadlock vs Livelock

These three are often confused.

Deadlock

Threads are blocked forever waiting on each other.

• No progress is possible for the involved threads.
• Classic cause: circular waiting on resources.

Starvation

A thread waits indefinitely because others keep getting access first.

• System as a whole may still make progress.
• The unlucky thread does not.

Example:

• A low-priority thread never gets CPU time.
• Writers never acquire a read-write lock because readers keep arriving.

Livelock

Threads are not blocked. They keep changing state in response to each other, but no useful work completes.

Example:

• Two threads repeatedly back off and retry at the same time forever.

Quick comparison

• Deadlock: stuck and waiting.
• Starvation: one participant keeps losing.
• Livelock: everyone is active but ineffective.

Interview one-liner

Deadlock means nobody can move, starvation means someone never gets a turn, and livelock means everyone keeps moving but nobody makes progress.

---

21. Thread Safety

Thread safety means code behaves correctly when accessed by multiple threads concurrently.

A thread-safe component typically guarantees one of these

• Internal synchronization protects shared mutable state.
• It is immutable after construction.
• It uses thread-local state.
• It relies only on atomic operations for correctness.
• It requires external synchronization and documents that requirement.

Common misconceptions

• Thread-safe does not mean fast.
• Thread-safe does not mean deadlock-free.
• Thread-safe does not mean lock-free.
• "Works most of the time" is not thread-safe.

Interview framing

When asked how to make something thread-safe, answer in layers:

1. Identify shared mutable state.
2. Define invariants that must always hold.
3. Choose synchronization or immutability strategy.
4. Minimize lock scope and avoid calling unknown code while locked.
5. Consider contention, fairness, and visibility.

---

22. Atomic Operations

Atomic operations are indivisible operations supported by hardware and exposed through runtimes or language libraries.

Common atomic operations:

• atomic load
• atomic store
• compare-and-swap (CAS)
• fetch-and-add
• exchange

Compare-and-swap intuition

CAS means:

1. Check whether memory still contains the expected value.
2. If yes, replace it with a new value atomically.
3. If no, fail and let caller retry.

This is foundational for lock-free algorithms.

Why atomics matter

• Efficient counters
• Lock-free queues and stacks
• Building higher-level locks
• Memory ordering and visibility guarantees

Important caveat

Atomic does not mean the entire high-level operation is correct.

Example:

• Multiple atomic variable updates together are not automatically atomic as a group.

Memory ordering note

In deeper interviews, mention that atomics can have different memory orders. Some guarantee only atomicity; others also impose stronger ordering and visibility semantics.

If the interviewer goes deeper, terms like acquire, release, and sequential consistency are relevant.

---

23. How These Concepts Appear in Backend Systems

1. Request handling in web servers

A server may use:

• one thread per request,
• a thread pool,
• or an event loop with background workers.

Concurrency issues show up in:

• shared caches,
• request counters,
• connection pools,
• session state,
• rate limiters.

2. Connection pools

Only a fixed number of DB connections exist.

• This is naturally modeled with a counting semaphore.
• Threads wait when the pool is exhausted.

3. In-memory caches

Concurrent reads and writes can corrupt internal state unless synchronized.

Possible designs:

• global mutex,
• sharded locks by key range,
• read-write lock,
• immutable snapshots with atomic pointer swaps.

4. Job queues and workers

Producer-consumer is everywhere:

• API tier produces jobs,
• workers consume them,
• bounded queues prevent overload,
• condition variables or blocking queues coordinate work.

5. Logging and metrics

Naive shared counters and buffers often create contention.

Production systems may use:

• atomic counters,
• per-thread buffers,
• batch flushing,
• lock-free ring buffers.

6. Distributed systems note

The same ideas reappear at larger scale:

• distributed locks,
• transactional deadlocks,
• leader election races,
• message ordering,
• idempotency instead of shared-memory locking.

Concurrency bugs do not disappear in distributed systems. They become harder because the scheduler is now the network.

---

24. Practical Patterns and Tradeoffs

Prefer less shared mutable state

The easiest race condition to fix is the one you never create.

Useful patterns:

• immutable objects,
• message passing,
• partitioning state by key,
• ownership transfer,
• copy-on-write,
• thread-local storage.

Minimize lock duration

Do not hold locks while doing:

• network I/O,
• disk I/O,
• long CPU computation,
• callbacks into unknown code.

Maintain lock ordering

If code may acquire multiple locks, impose a consistent global order.

This is one of the most practical deadlock prevention techniques.

Beware of hidden lock boundaries

Deadlocks often involve:

• library calls,
• logging inside locked code,
• callback re-entry,
• nested object methods each taking locks.

Measure contention

A correct locking strategy can still fail performance goals if contention is high.

Symptoms:

• high CPU with low throughput,
• many blocked threads,
• tail latency spikes,
• reduced scaling as cores increase.

---

25. Common Interview Questions and How to Think About Them

"What is the difference between concurrency and parallelism?"

Answer with both concept and example.

Good answer:

Concurrency is about multiple tasks making progress during the same time window, often by interleaving. Parallelism is about tasks literally running at the same instant on different cores. A single-core event loop is concurrent but not parallel.

"What is a race condition?"

Say more than "two threads access the same variable."

Good answer:

A race condition happens when correctness depends on timing or interleaving between concurrent operations. A common case is unsynchronized shared mutable state, where non-atomic read-modify-write leads to lost updates.

"What is the critical section problem?"

Good answer:

It is the problem of designing a protocol so threads sharing data can enter critical sections safely while satisfying mutual exclusion, progress, and bounded waiting.

"Mutex vs semaphore?"

Good answer:

A mutex provides mutual exclusion and usually has ownership semantics. A semaphore is a counter-based signaling primitive. Binary semaphores can resemble locks, but counting semaphores are better for controlling access to N identical resources.

"When would you use a spinlock?"

Good answer:

Only when the expected wait is extremely short and the cost of sleeping is higher than busy-waiting, such as in low-level systems code. Under long waits or high contention, spinlocks waste CPU.

"How do deadlocks happen and how do you prevent them?"

Good answer:

Deadlocks require mutual exclusion, hold-and-wait, no preemption, and circular wait. In application code, the most practical prevention strategy is global lock ordering and minimizing nested lock acquisition.

"What is starvation? What is livelock?"

Good answer:

Starvation means a thread never gets the resource or CPU time it needs even though others continue to make progress. Livelock means threads keep reacting to each other and changing state, but no useful progress is made.

"How would you make a class thread-safe?"

Good answer structure:

1. Identify shared mutable state.
2. Define invariants.
3. Choose a strategy: immutability, mutex, RW lock, atomics, or confinement.
4. Keep lock scope minimal.
5. Validate performance and deadlock risk.

---

26. Practical Interview Scenarios

Scenario 1: Shared counter for analytics

Question:

"Many threads increment a global request counter. What can go wrong and how would you fix it?"

What interviewer wants:

• identify lost updates,
• explain why count++ is not atomic,
• propose mutex or atomic increment,
• discuss contention if traffic is high.

Strong extension:

For very high update rates, I might use per-thread counters and periodically aggregate them, because a single atomic counter can become a contention hotspot.

Scenario 2: Thread-safe LRU cache

Question:

"How would you make an LRU cache thread-safe?"

Strong approach:

• The map and linked list must remain consistent together.
• A coarse mutex is the simplest correct approach.
• If reads dominate and performance matters, consider sharding or redesign.
• Beware of callbacks, eviction hooks, or loaders that run while holding the lock.

Scenario 3: Database connection pool

Question:

"Which primitive fits best?"

Strong answer:

A counting semaphore fits naturally because it tracks how many connections are available. The actual pool data structure still needs synchronization, but the semaphore models resource capacity cleanly.

Scenario 4: Avoiding deadlock with two resources

Question:

"Two threads sometimes need both lock A and lock B. How do you avoid deadlock?"

Strong answer:

Enforce lock ordering. Always acquire A before B everywhere in the codebase. If order cannot be guaranteed, use try-lock with backoff or redesign to reduce nested locking.

Scenario 5: Producer-consumer queue overload

Question:

"Workers are slower than producers. What should happen?"

Strong answer:

Use a bounded queue so memory usage cannot grow without limit. Producers should block, shed load, or apply backpressure once the queue is full.

That answer shows system thinking, not just API knowledge.

---

27. A Good Mental Model for Solving Concurrency Questions

When you see a concurrency problem, reason in this order:

1. What state is shared?
2. What invariants must remain true?
3. Who can read or write the state concurrently?
4. Is the problem about exclusion, ordering, visibility, or all three?
5. Which primitive best matches the need?
6. Could deadlock, starvation, or contention appear?
7. Can the design reduce sharing instead of synchronizing more?

This is often what separates a strong interview answer from a memorized one.

---

28. High-Value Takeaways to Remember

• Concurrency is about coordinating multiple in-progress tasks.
• Parallelism is about simultaneous execution.
• Race conditions happen when correctness depends on timing.
• Critical sections protect shared mutable state.
• Mutual exclusion solves only one part of synchronization.
• Mutexes protect exclusive access.
• Semaphores coordinate access to counted resources or events.
• Condition variables let threads wait for state changes.
• Spinlocks trade CPU for low waiting latency.
• Monitors package state and synchronization together.
• Deadlock requires all four Coffman conditions.
• Starvation, deadlock, and livelock are different failure modes.
• Thread safety is about correctness under concurrent access, not just locking.
• Atomic operations are building blocks, not magic.
• In real systems, the best design often reduces shared state instead of adding more locks.

---

29. Final Interview Advice

For OS and systems interviews, aim to answer at three levels:

1. Definition Show you know the term precisely.
2. Mechanism Explain how it works and what guarantees it provides.
3. Tradeoff and application Show when you would use it in real systems and what can still go wrong.

That combination makes your answers sound like engineering judgment rather than memorization.

If you can explain:

• why count++ is unsafe,
• why while is used around condition waits,
• why lock ordering prevents deadlocks,
• when semaphores fit better than mutexes,
• and how these ideas appear in caches, queues, pools, and services,

you are already operating at a strong interview level.