Coordination Anti-Patterns — Interview Q&A¶

Category: Concurrency Anti-Patterns → Coordination — two or more lock holders that fail to make progress together. Covers (collectively): Lock Ordering Inconsistency → Deadlock · Holding a Lock During I/O · Wrong Lock Granularity

A bank of 60+ interview questions spanning recognition, prevention, debugging, and the runtime cost of contention. Each answer models the reasoning a strong candidate gives — including the trade-offs, because coordination problems almost never have a free fix. Examples are Go and Java first, with a Python/GIL note where it changes the answer. Use the <details> toggles to self-quiz: read the question, answer out loud, then expand.

Table of Contents¶

1. Fundamentals / Junior
2. Intermediate / Middle
3. Senior — Prevention, Avoidance, Detection & Lock Hierarchies
4. Professional / Deep — Contention Cost, Convoys, Mutex Internals
5. Code-Reading — Spot the Deadlock / Lock-Across-I/O
6. Curveballs
7. Rapid-Fire / One-Liners
8. How to Talk About Coordination in Interviews
9. Summary
10. Related Topics

Fundamentals / Junior¶

Definitions, recognition, and the "why is it bad" reasoning.

Q1. Name the three coordination anti-patterns and give a one-line symptom for each.

Q2. What is a critical section?

Q3. What is a deadlock, in one sentence, and what makes it different from a normal slow program?

Q4. Show the smallest possible deadlock in Go.

var muA, muB sync.Mutex

func f1() { muA.Lock(); muB.Lock(); /* ... */ muB.Unlock(); muA.Unlock() }
func f2() { muB.Lock(); muA.Lock(); /* ... */ muA.Unlock(); muB.Unlock() }

Q5. Why is "holding a lock during a network call" dangerous even if the code is otherwise correct?

Q6. What does "lock granularity" mean?

Q7. Does a deadlock corrupt data?

Q8. What's the difference between a deadlock, a livelock, and starvation?

Q9. Why are these bugs so hard to reproduce?

Q10. If two threads only ever need one lock at a time, can they deadlock on those locks?

Q11. What is the GIL, and how does it change this conversation in Python?

Intermediate / Middle¶

When it creeps in, what to do instead, and the trade-offs.

Q12. What is the standard fix for a lock-ordering deadlock?

Q13. Show the classic "transfer between two accounts" deadlock and the ordered fix.

void transfer(Account from, Account to, long amt) {
    synchronized (from) {
        synchronized (to) { from.debit(amt); to.credit(amt); }
    }
}

void transfer(Account from, Account to, long amt) {
    Account first  = from.id < to.id ? from : to;
    Account second = from.id < to.id ? to   : from;
    synchronized (first) {
        synchronized (second) { from.debit(amt); to.credit(amt); }
    }
}

Q14. Walk through the "copy, release, then do I/O" refactor.

func (c *Cache) Refresh(key string) {
    c.mu.Lock()
    defer c.mu.Unlock()
    v := httpGet(key)        // network call under the lock — blocks all others
    c.data[key] = v
}

func (c *Cache) Refresh(key string) {
    v := httpGet(key)        // no lock held during the slow part
    c.mu.Lock()
    c.data[key] = v          // lock held only for the fast map write
    c.mu.Unlock()
}

Q15. After "copy-then-I/O," two threads might do the same expensive fetch. Is that acceptable?

Q16. Is finer-grained locking always faster?

Q17. How do you choose the right lock granularity?

Q18. What is lock striping?

Q19. What's the difference between a mutex and a read-write lock, and when does RWLock help?

Q20. How does defer mu.Unlock() in Go interact with lock-during-I/O bugs?

Q21. What are the warning signs in code review that someone holds a lock too long?

Q22. A method is synchronized and calls another synchronized method on a different object. What should worry you?

Q23. Java: is synchronized reentrant? Why does that matter here?

Q24. Should you use tryLock with a timeout to "fix" deadlocks?

Senior — Prevention, Avoidance, Detection & Lock Hierarchies¶

Strategy, debugging in production, and refactoring contended paths.

Q25. What are the four Coffman conditions for deadlock?

Q26. Map each common deadlock-prevention technique to the Coffman condition it breaks.

Q27. Distinguish deadlock prevention, avoidance, and detection.

Q28. What is a lock hierarchy / lock leveling, and how do you enforce it?

Q29. How do you debug a deadlock in production?

Q30. You profile a hot path and the bottleneck is lock contention. What's your decision tree?

Q31. A lock is heavily contended but each critical section is tiny. What now?

Q32. How do you prevent deadlock? Give the full menu, ranked.

Q33. How do you refactor a contended path that holds a lock across a DB query?

Q34. Two locks that are always taken together — should you merge them?

Q35. What is the relationship between lock granularity and Amdahl's Law?

Q36. When is one big lock actually the right call?

Q37. Your service deadlocks only under high load in production but never in tests. Why, and what do you do?

Professional / Deep — Contention Cost, Convoys, Mutex Internals¶

Runtime, memory ordering, and the hardware reality under the lock.

Q38. What actually happens, at the hardware/OS level, when a lock is contended?

Q39. What is a lock convoy?

Q40. Why can an unfair lock outperform a fair one?

Q41. Does holding a lock guarantee memory visibility, and how does that connect to granularity?

Q42. How does false sharing relate to fine-grained locking?

Q43. Compare the cost models of a mutex, an RWLock, and an atomic for protecting a single counter.

Q44. What does Go's -race detector actually catch, and what does it miss regarding these anti-patterns?

Q45. How do databases handle deadlock, and what can application code learn from it?

Q46. Reentrant vs. non-reentrant locks — what's the deep trade-off?

Code-Reading — Spot the Deadlock / Lock-Across-I/O¶

You're shown a snippet; identify the anti-pattern and state the fix.

Q47. Spot the problem and fix it (Go).

func (s *Store) Update(id string, v Value) error {
    s.mu.Lock()
    defer s.mu.Unlock()
    if err := s.db.Exec("UPDATE ... WHERE id=$1", id); err != nil { // DB call under lock
        return err
    }
    s.cache[id] = v
    return nil
}

func (s *Store) Update(id string, v Value) error {
    if err := s.db.Exec("UPDATE ... WHERE id=$1", id); err != nil {
        return err
    }
    s.mu.Lock()
    s.cache[id] = v
    s.mu.Unlock()
    return nil
}

Q48. Spot the problem (Java).

class Account {
    final Object lock = new Object();
    void transferTo(Account other, long amt) {
        synchronized (lock) {
            synchronized (other.lock) {
                this.balance -= amt;
                other.balance += amt;
            }
        }
    }
}

void transferTo(Account other, long amt) {
    Account lo = System.identityHashCode(this) <= System.identityHashCode(other) ? this : other;
    Account hi = lo == this ? other : this;
    synchronized (lo.lock) {
        synchronized (hi.lock) { this.balance -= amt; other.balance += amt; }
    }
}

Q49. Is there a deadlock here (Go)?

func process(jobs <-chan Job, mu *sync.Mutex, out chan<- Result) {
    for j := range jobs {
        mu.Lock()
        out <- compute(j)   // blocking channel send while holding the lock
        mu.Unlock()
    }
}

for j := range jobs {
    mu.Lock()
    r := compute(j)
    mu.Unlock()
    out <- r            // block on the channel with no lock held
}

Q50. Name the granularity problem (Java).

class Registry {
    private final Map<String, Conn> conns = new HashMap<>();
    public synchronized Conn get(String k) { return conns.get(k); }
    public synchronized void put(String k, Conn c) { conns.put(k, c); }
    public synchronized int size() { return conns.size(); }
    public synchronized void ping(String k) { conns.get(k).ping(); } // ping() does network I/O
}

private final Map<String, Conn> conns = new ConcurrentHashMap<>();
public Conn get(String k) { return conns.get(k); }
public void put(String k, Conn c) { conns.put(k, c); }
public int size() { return conns.size(); }
public void ping(String k) {
    Conn c = conns.get(k);          // concurrent, fine-grained
    if (c != null) c.ping();        // network call with no lock held
}

Q51. Spot the subtle deadlock (Java callback).

class EventBus {
    private final List<Listener> listeners = new ArrayList<>();
    synchronized void register(Listener l) { listeners.add(l); }
    synchronized void publish(Event e) {
        for (Listener l : listeners) l.onEvent(e); // calls user code while holding the lock
    }
}

void publish(Event e) {
    List<Listener> snapshot;
    synchronized (this) { snapshot = new ArrayList<>(listeners); }
    for (Listener l : snapshot) l.onEvent(e);   // no lock held during callbacks
}

Q52. Which anti-pattern, and is it actually wrong (Go)?

type Counter struct {
    mu sync.Mutex
    n  int64
}
func (c *Counter) Inc() { c.mu.Lock(); c.n++; c.mu.Unlock() }

type Counter struct{ n atomic.Int64 }
func (c *Counter) Inc() { c.n.Add(1) }

Curveballs¶

The questions designed to catch glib answers.

Q53. How do you prevent deadlock?

Q54. Is finer-grained locking always faster?

Q55. Why is holding a lock during a network call dangerous?

Q56. What are the four conditions for deadlock?

Q57. "We added more locks and it got slower." How is that possible?

Q58. Can you deadlock with a single lock?

Q59. Channels in Go avoid locks — so they can't deadlock, right?

Q60. The database has a deadlock detector — so why should application code bother preventing deadlock?

Rapid-Fire / One-Liners¶

Crisp answers; what an interviewer wants in one or two sentences.

Q61. One-line cure for each of the three?

Q62. The four Coffman conditions, in four words?

Q63. The fastest tell of a deadlock in monitoring?

Q64. Prevention vs. detection in one line?

Q65. When does an RWLock beat a mutex?

Q66. Why doesn't Go's -race catch deadlocks?

Q67. Does the GIL prevent Python deadlocks?

Q68. Coarse vs. fine locking in one sentence?

Q69. The single best way to avoid lock-ordering deadlock?

How to Talk About Coordination in Interviews¶

A few habits separate a strong answer from a textbook recital:

• Lead with the failure mode, not the label. Don't just say "deadlock" — say "two threads each hold one lock and wait for the other; it's permanent and shows as a hung-but-idle process." The mechanism is the signal.
• Always name the trade-off. Every fix here costs something: ordering needs discipline and documentation, copy-then-I/O opens a staleness window, finer locks add overhead and new deadlock surface. "It depends, and here's on what" beats absolutism.
• Map fixes to Coffman conditions. Saying "global ordering breaks circular wait; lock-free breaks mutual exclusion" demonstrates you understand why the fix works, not just that it does.
• Insist on measuring before optimizing granularity. "I'd start with one lock, ship it, then split only what the contention profile proves is hot" is a senior signal; reflexive fine-graining is a juniorism.
• Show how you'd debug it in prod. Thread/goroutine dumps, the wait-for cycle, block/mutex profilers, stress tests with jitter — this proves you've actually chased one, not just read about it.
• Don't claim a primitive is a silver bullet. Channels, RWLocks, the GIL, and DB deadlock detectors all have boundaries; knowing where each doesn't help is the deeper answer.
• Use a concrete story. "Our service deadlocked only at peak; the jstack dump showed a cache lock and a metrics lock taken in opposite orders on two paths — we leveled the locks and it never recurred" lands harder than any definition.

Summary¶

• The three coordination anti-patterns are liveness failures, not correctness failures: the locking is race-free, yet threads fail to progress together (deadlock), or progress far too slowly (lock-during-I/O, wrong granularity).
• Deadlock needs all four Coffman conditions; breaking any one prevents it. In practice you break circular wait with a documented global lock order (or avoid hold-and-wait by holding one lock at a time); databases break no-preemption via detect-and-abort.
• Holding a lock during I/O multiplies an uncontrolled latency across every contending thread — the cure is structural: copy under the lock, release, do the I/O, re-lock briefly to publish, adding single-flight or version checks if the unlocked window matters.
• Granularity is a measured trade: too coarse caps scalability (Amdahl's serial fraction); too fine adds overhead, false sharing, and new ordering bugs. Start coarse, profile, and split only proven hotspots — finer is not automatically faster.
• The deep layer is the cost of contention itself: cache-line ping-pong, park/unpark context switches, convoys, and the fairness-vs-throughput trade. Locks also provide memory visibility (happens-before), so you can't shrink a critical section into incorrectness.
• The strongest answers lead with the mechanism and cost, name the trade-off, map cures to Coffman conditions, and measure before optimizing granularity.

Related Topics¶

• junior.md — recognize each coordination failure and why it's hard to reproduce.
• middle.md — lock ordering, copy-then-I/O, and sizing locks; the everyday countermoves.
• senior.md — prevention vs. detection, lock hierarchies, debugging a deadlock in prod.
• professional.md — contention cost, convoys, mutex internals, memory ordering.
• tasks.md · find-bug.md · optimize.md — practice the diagnosis and the fix.
• Synchronization Misuse — double-checked locking, volatile misuse, race-prone lazy init.
• Shared State — unprotected shared mutable state, busy-waiting, unbounded thread-per-request (see the chapter overview).
• Async Anti-Patterns — the single-threaded event-loop sibling chapter (async deadlocks).
• Concurrency Anti-Patterns (chapter) — how all nine relate, rooted in shared mutable state.
• Clean Code → Concurrency — positive patterns: keep critical sections small, prefer immutability.
• Clean Code → Immutability — the structural cure that removes the shared writes (and the locks) entirely.
• Distributed Systems — coordination, locking, and deadlock at the network scale.