Concurrency and Synchronization Questions

Covers the principles and practical techniques for safely coordinating concurrent execution and access to shared resources. Topics include models of concurrency such as threads, processes, interrupt handlers, and tasks in a real time operating system; differences between preemptive and cooperative scheduling; shared data hazards including race conditions and read modify write hazards; critical sections and approaches to protect them including disabling interrupts in embedded contexts and scoped locks. Synchronization primitives and patterns are included: mutexes, binary semaphores, counting semaphores, condition variables, message queues, atomic operations and lock free primitives such as compare and swap. Memory ordering concerns and memory barrier usage on multi core systems are covered, along with priority inversion and priority inheritance. Also addressed are deadlock, livelock, and starvation concepts and avoidance strategies, granularity and performance trade offs of locking, and practical synchronization patterns. Preparation should include identifying and fixing races in code, designing correct concurrent interfaces, and debugging and testing techniques such as stress testing, instrumentation, deterministic replay, race detectors, static analysis, and code review strategies.

MediumTechnical

49 practiced

You have an intermittent race that corrupts packet length field occasionally. Propose a debugging and test plan tailored for an embedded target with limited tracing capability. Include lightweight instrumentation to capture time-ordered events, stress test strategies, and ideas for deterministic replay or reproduction on host hardware.

Sample Answer

**Plan summary**Start with low-impact time-ordered event capture on-device, add targeted stress tests to increase race probability, and create deterministic replay paths on host for diagnosis.

**Lightweight instrumentation**- Use a lock-free, fixed-size circular event buffer in RAM to record (timestamp, event_id, payload_ptr/short val). Dump over serial or on crash.- Example ring buffer writer (minimal, IRQ-safe):

// atomic index assumed on 32-bit
volatile uint32_t idx;
struct evt { uint32_t t; uint16_t id; uint16_t val; } evts[256];
void log_evt(uint16_t id, uint16_t val){
  uint32_t i = __atomic_fetch_add(&idx, 1, __ATOMIC_RELAXED) & 255;
  evts[i].t = hw_timestamp();
  evts[i].id = id; evts[i].val = val;
}

- Instrument around packet assembly, DMA handoffs, ISR entry/exit, and length-field writes/reads.

**Stress test strategies**- Rapid-fire packet generation with varying sizes and alignment.- Inject noise: deliberately delay ISR or task scheduling to change interleaving.- Run under different optimization/builds (O0/O2), and with/without compiler/barrier hints.

**Deterministic replay**- Capture inputs (raw bytes from PHY, timing deltas) via host-side harness.- Reproduce with a cycle-accurate model or instrumented simulator; if not available, stub hardware calls and feed recorded inputs deterministically.- On-host, enable sanitizer/TSAN-like tools or annotate critical sections to detect races.

**Debugging steps**1. Reproduce with stress harness; collect ring buffer dumps when corruption seen.2. Correlate timestamps to find concurrent writers/readers.3. Narrow to minimal reproducer; add asserts and temporary locks to validate hypothesis.4. Fix (atomic ops/barriers or restructure ownership) and verify by regression stress tests.

**Notes**Keep logs tiny, avoid blocking in ISR, and rotate or mark overflows so you know if you missed events.

HardTechnical

51 practiced

Provide a code sketch and algorithm for a lock-free reference-counted shared buffer usable by multiple readers and single writer. Explain necessary atomic operations, memory ordering, and how to safely reclaim the buffer when the final reference is released, including corner cases where a reader may still be accessing data during reclamation.

Sample Answer

**Approach (brief)** Use an atomic pointer to the buffer plus an internal atomic reference count inside the buffer. Readers atomically load pointer, increment its refcount, then re-check pointer stability; writer allocates new buffer, atomically swaps pointer, then decrements the old buffer's refcount and frees if it reaches zero. Use acquire/release ordering to ensure visibility and avoid data races.

**Code sketch (C, embedded-friendly)**

#include <stdatomic.h>
#include <stdlib.h>

typedef struct Buffer {
    atomic_int ref;      // reference count
    size_t len;
    uint8_t data[];      // flexible array
} Buffer;

atomic_uintptr_t g_buf_ptr = ATOMIC_VAR_INIT((uintptr_t)NULL);

// reader: returns pointer to buffer (caller must release)
Buffer* buf_acquire(void) {
    for (;;) {
        uintptr_t p = atomic_load_explicit(&g_buf_ptr, memory_order_acquire);
        Buffer* b = (Buffer*)p;
        if (!b) return NULL;
        // increase refcount
        atomic_fetch_add_explicit(&b->ref, 1, memory_order_acq_rel);
        // verify pointer unchanged
        if ((uintptr_t)b == atomic_load_explicit(&g_buf_ptr, memory_order_acquire))
            return b;
        // pointer changed: drop our ref and retry
        if (atomic_fetch_sub_explicit(&b->ref, 1, memory_order_acq_rel) == 1) {
            // last ref; safe to reclaim
            // ensure prior writes are visible before free
            atomic_thread_fence(memory_order_acquire);
            free(b);
        }
    }
}

void buf_release(Buffer* b) {
    if (!b) return;
    if (atomic_fetch_sub_explicit(&b->ref, 1, memory_order_acq_rel) == 1) {
        atomic_thread_fence(memory_order_acquire);
        free(b);
    }
}

// writer replaces buffer atomically
void buf_replace(Buffer* newb) {
    // newb should have initial ref == 1 for writer ownership
    uintptr_t oldp = atomic_exchange_explicit(&g_buf_ptr, (uintptr_t)newb, memory_order_acq_rel);
    Buffer* oldb = (Buffer*)oldp;
    if (oldb) {
        if (atomic_fetch_sub_explicit(&oldb->ref, 1, memory_order_acq_rel) == 1) {
            atomic_thread_fence(memory_order_acquire);
            free(oldb);
        }
    }
}

**Key atomic operations and memory ordering**- atomic_load(memory_order_acquire) when reading pointer: ensures subsequent reads of buffer data see initialized content.- atomic_fetch_add/sub(memory_order_acq_rel): increment/decrement refcount with combined acquire-release semantics to synchronize readers/writer.- atomic_exchange(memory_order_acq_rel) for swap to publish new buffer and get old pointer.- atomic_thread_fence(memory_order_acquire) before free ensures prior releases are observed.

**Safety & corner cases**- ABA: if pointer can flip between same addresses (rare if buffers are freshly malloc'd). For embedded with limited allocator reuse, include a version/tag in pointer (combine pointer+counter) to avoid ABA.- Reader preemption between load and increment: solved by increasing refcount after load and verifying pointer unchanged; if changed, decrement and retry.- Reclamation: only free when refcount transitions to zero; the last releaser uses acquire fence before free to ensure safe reclamation.- Single writer simplifies (no concurrent writer-writer ABA), but if multiple writers exist, use CAS loop or a pointer+version and ensure writer increments newb->ref appropriately.

**Why this is correct**- Readers hold a ref while accessing data; writer frees only when ref==0 so no reader can be accessing memory being freed.- Acquire/release pairs ensure proper visibility ordering between writer initialization of buffer and readers seeing that data.- The re-check after increment prevents the race where pointer changed after the reader incremented a stale buffer.

This pattern is compact, lock-free for readers, and suitable for resource-constrained embedded systems.

HardTechnical

58 practiced

Design and implement a real-time safe try-lock with timeout for an embedded RTOS. The API should allow immediate try_lock (non-blocking), timed_lock (block up to timeout), and unlock. Discuss how you handle priority inversion, how you measure and bound worst-case blocking time, and how you would implement this efficiently on resource-limited systems.

Sample Answer

**Approach (brief)**Use a small RT-safe mutex with non-blocking try_lock, timed_lock (busy-wait or wait on RTOS primitive with priority inheritance), and unlock. Provide bounded blocking by using kernel tick timeout and optional priority inheritance (PI) or priority ceiling.

**Code (C, simplified)**

// simple RT-safe trylock with timeout (ticks)
// Assumes RTOS primitives: enter_critical()/exit_critical(), sleep_ticks(), get_ticks(), set_owner_priority()
typedef struct {
  volatile int locked;      // 0 or 1
  int owner;                // thread id
  uint8_t owner_prio;       // original priority for PI restore
} rt_trylock_t;

int try_lock(rt_trylock_t *m) {
  enter_critical();
  if (!m->locked) { m->locked = 1; m->owner = self_id(); exit_critical(); return 0; }
  exit_critical();
  return -1; // busy fail
}

int timed_lock(rt_trylock_t *m, uint32_t timeout_ticks) {
  uint32_t start = get_ticks();
  while (1) {
    enter_critical();
    if (!m->locked) { m->locked = 1; m->owner = self_id(); exit_critical(); return 0; }
    // priority inheritance: raise owner's priority to current if lower
    int owner = m->owner;
    if (owner_valid(owner)) {
      uint8_t myp = get_my_priority(), op = m->owner_prio ? m->owner_prio : get_priority(owner);
      if (op > myp) { /* lower numerically = higher prio */ set_owner_priority(owner, myp); m->owner_prio = op; }
    }
    exit_critical();
    if (get_ticks() - start >= timeout_ticks) return -2; // timeout
    sleep_ticks(1); // sleep short; bounded by timeout
  }
}

void unlock(rt_trylock_t *m) {
  enter_critical();
  if (m->owner != self_id()) { exit_critical(); return; } // error
  // restore priority
  if (m->owner_prio) set_owner_priority(m->owner, m->owner_prio);
  m->owner_prio = 0;
  m->locked = 0; m->owner = -1;
  exit_critical();
}

**Key concepts & reasoning**- try_lock is non-blocking; timed_lock loops but sleeps a tick to allow preemption — avoids unbounded busy-spin on low-power systems.- Priority inversion: implement simple PI by temporarily boosting owner to requester's priority (or use RTOS native PI mutex). Prefer priority ceiling if static resource set known (zero inversion, simpler WCET).- Worst-case blocking bound: at most sum of critical sections of higher-priority holder plus one tick of sleep granularity. To bound formally, use priority ceiling or disallow nested locking; measure maximum critical section lengths and add tick granularity.- Efficiency: keep state small (one word), use enter_critical()/exit_critical() for atomicity to avoid heavy kernel objects; on systems with kernel mutex support use that for lower CPU cost.- Edge cases: nested locks, owner crash/death, nested PI propagation; prefer kernel-provided real-time mutex where available.

HardSystem Design

61 practiced

Design the concurrency architecture for a sensor-fusion pipeline on a dual-core MCU: multiple sensor interrupts (accelerometer, gyroscope), DMA transfers, and a fusion algorithm with tight real-time deadlines. Specify how you partition work across cores, how data is handed off (DMA -> ISR -> task), synchronization primitives used, and how you ensure deterministic latency for the fusion step.

Sample Answer

**Overview & constraints**I would partition for determinism: dedicate Core 0 to hard real-time I/O (DMA, ISRs) and Core 1 to compute-heavy fusion. This minimizes ISR jitter and keeps the fusion deadline predictable.

**Partitioning**- Core 0: configure sensors, DMA controllers, handle sensor ISRs, maintain lock‑free FIFOs / double buffers, run a lightweight RTOS (or bare-metal) scheduler for I/O tasks.- Core 1: run the fusion algorithm at a fixed periodic high priority task, signal-driven by Core 0.

**Data handoff (DMA -> ISR -> task)**- DMA writes into a pre-allocated, cache-aligned double buffer per sensor with sequence counters.- On DMA completion, DMA triggers ISR on Core 0. ISR: - Performs minimal checks (sequence, CRC), flips the buffer pointer atomically, and enqueues a pointer to the filled buffer into a lock-free SPSC queue (or writes to a shared ring with single producer). - Posts an inter-core event (hardware semaphore or RTOS inter-core notification) to wake Core 1.- Core 1 consumes buffers in order, reads sensor timestamps, and runs fusion.

**Synchronization primitives**- Use single-producer single-consumer (SPSC) lock-free queues for sensor -> fusion transfer to avoid locks and priority inversion.- Use hardware mailbox / semaphore or RTOS inter-core notifications for low-latency wakeups.- Use atomic sequence counters and memory barriers when swapping buffers to ensure visibility across cores.- Use priority inheritance only if using mutexes for shared configuration; prefer lock-free designs.

**Deterministic latency for fusion**- Pin fusion task to Core 1, set fixed real-time priority, and use deadline-monotonic/static cyclic scheduler so fusion runs at fixed interval (e.g., 1 kHz) with CPU budget measured.- Pre-allocate and align all memory; avoid dynamic allocation during runtime.- Disable or tightly bound nonessential interrupts on Core 1; any cross-core interrupts only for notifications.- Use double/triple buffering so fusion never waits for DMA; if buffers backlog, drop oldest with counters and log.- Measure WCET for fusion (with worst-case inputs), add safety margin, and configure watchdog to detect missed deadlines.- If necessary, offload compute to DSP/FPU or vectorize to guarantee budget.

**Trade-offs & robustness**- This gives low ISR jitter and deterministic fusion timing at cost of dedicating one core to I/O. Alternatives: split sensors across cores or use prioritized threads, but risk more jitter. Add runtime monitoring to detect sensor stalls, and use timing counters for traceability.

EasyTechnical

55 practiced

Analyze the following C snippet and identify potential concurrency issues when both an ISR and the main thread access the shared counter:

volatile uint32_t counter;
void SysTick_Handler(void) { counter++; }
int main(void) {
  while(1) {
    if (counter >= 100) { counter = 0; /* process event */ }
  }
}

Explain why this is unsafe and suggest two minimal fixes suitable for a small microcontroller.

Sample Answer

**Why this is unsafe**- counter++ in the ISR and the read/assign in main are concurrent. On many small MCUs a 32-bit load/store is not atomic (may be multiple bus cycles), so main can read a torn value or overwrite increments: race condition and lost updates. volatile only prevents compiler optimizations — it does NOT make accesses atomic or provide synchronization.

**Consequences**- Missed increments (lost events), corrupted reads, or infinite loops if torn value compares wrong.

**Two minimal fixes (with examples)**

1) Short critical section: disable interrupts around the read/modify/reset in main. Minimal, predictable, and portable for bare-metal:

volatile uint32_t counter;

int main(void) {
  uint32_t c;
  while (1) {
    __disable_irq();           // CMSIS intrinsic: mask interrupts
    c = counter;
    if (c >= 100) {
      counter = 0;
    }
    __enable_irq();
    if (c >= 100) { /* process event outside critical section */ }
  }
}

- Keeps the interrupt disabled only for a few cycles, preventing torn reads/writes.

2) Use an atomic type or hardware-supported atomic ops (if toolchain/arch supports C11 atomics or exclusive load/store). Example with C11 atomics:

#include <stdatomic.h>
atomic_uint_fast32_t counter;

void SysTick_Handler(void) { atomic_fetch_add_explicit(&counter, 1, memory_order_relaxed); }

int main(void) {
  uint32_t c = atomic_load_explicit(&counter, memory_order_relaxed);
  if (c >= 100) {
    atomic_store_explicit(&counter, 0, memory_order_relaxed);
    /* process event */
  }
}

- Provides lock-free atomicity if implemented by the platform; no interrupt masking needed.

**Pick based on constraints**- If no atomics/library support: use interrupt masking (fix 1).- If you need non-blocking behavior and toolchain supports it: prefer C11 atomics or architecture-exclusive instructions for cleaner concurrency.

Unlock Full Question Bank

Get access to hundreds of Concurrency and Synchronization interview questions and detailed answers.

Join thousands of developers preparing for their dream job.