Concurrency, Synchronization & Deadlock Questions

Key differences (high level)

• ARMv7-M (Cortex‑M): strongly ordered for single-core, but still allows write buffering and reordering relative to DMA/peripherals; typically no cache on M-class, so barriers control peripheral visibility (DMB enforces order, DSB ensures completion).
• ARMv8-A (Cortex‑A): weakly-ordered, multicore, cache-coherent but requires explicit cache maintenance (clean/invalidate) plus DSB/DMB for correct visibility between cores and devices.
• x86: TSO (stronger than ARMv8-A). Stores have release semantics and loads acquire, so many explicit fences are unnecessary; use MFENCE/SFENCE/LFENCE only for specific weak ordering like non-temporal stores.

Two concrete buggy scenarios from forgetting DMB/DSB

1. DMA reads CPU-prepared buffer (Cortex‑M):

• Sequence: CPU fills buffer, starts DMA by writing peripheral registers, then returns.
• Bug: Without a DSB (and on cacheful systems a cache clean), buffered CPU stores may not reach RAM before DMA reads—DMA reads stale data.
• Fix: After filling buffer do a DSB (ensure stores complete) and on Cortex‑A also clean cache lines for the buffer, then start DMA.

2. Inter-core producer/consumer flag (Cortex‑A multicore):

• Sequence: Producer writes data[ ] then writes flag = 1. Consumer polls flag then reads data[].
• Bug: Without a DMB on producer and proper cache clean/invalidate, the flag update or data may be observed out of order by other core—consumer may see flag=1 but stale data or vice versa.
• Fix: Producer: write data[], perform DSB then clean cache lines, then DMB, then write flag (or use store-release). Consumer: on seeing flag, DMB then invalidate or read after ensuring cache line invalidation.

Why x86 behaves differently

• On x86 the producer store to data then flag is ordered for other cores (store → store ordering preserved), so explicit fences usually not required; DMA/device cases still need cache flush/flush-to-memory.

Takeaway (practical rules)

• For DMA: ensure CPU stores complete (DSB) and clean caches; after DMA completes, DMB/DSB + invalidate before CPU reads.
• For inter-core: use DMB (or appropriate release/acquire primitives) plus cache maintenance on cached systems; rely on architecture-provided stronger ordering (x86) only when targeting x86.

Problem / atomicity issue
On a 32-bit MCU a 64-bit counter split into two 32-bit registers can be torn: the main thread may read the low half and then be preempted while the ISR increments the low half and carries to the high half. The main thread then reads the high half — producing an inconsistent value.

Safe approaches (>=2)

1) Disable interrupts around the 64-bit access

• Simple, deterministic, minimal code.
• Use a critical section so read/write is non-preemptible.

#include <stdint.h>
volatile uint32_t ts_low, ts_high;

uint64_t read_ts(void) {
    uint32_t prim = __get_PRIMASK();    // save interrupt state (Cortex-M example)
    __disable_irq();
    uint64_t v = ((uint64_t)ts_high << 32) | ts_low;
    if (!prim) __enable_irq();          // restore
    return v;
}

• Use same pattern when updating from thread context. Keep critical sections short.

2) Read-with-validation (double-read or sequence counter)

• No disabling interrupts; good when interrupts must stay enabled.

Double-read method:

uint64_t read_ts_safe(void) {
    uint32_t hi1, lo, hi2;
    do {
        hi1 = ts_high;
        lo  = ts_low;
        hi2 = ts_high;
    } while (hi1 != hi2);
    return ((uint64_t)hi1 << 32) | lo;
}

Sequence-counter method (ISR increments seq before/after update):

volatile uint32_t seq;
volatile uint32_t ts_low, ts_high;

uint64_t read_ts_seq(void) {
    uint32_t s;
    uint32_t hi, lo;
    do {
        s = seq;
        if (s & 1) continue;            // writer in progress
        hi = ts_high;
        lo = ts_low;
    } while (s != seq);
    return ((uint64_t)hi << 32) | lo;
}

Notes / best practices

• Mark shared variables volatile.
• Ensure proper memory barriers if compiler reorders (use atomic/volatile or compiler intrinsics).
• Keep critical sections short; prefer validation method if ISR latency must be minimal.

Overview
Brief comparison of three RTOS primitives used for synchronization in embedded systems.

Mutex

• Ownership semantics: Owned by the task that locks it; only owner should unlock. Often supports priority inheritance.
• Blocking behavior: Tasks block when mutex is unavailable; designed for mutually exclusive access to resources.
• ISR safety: Not safe — ISRs must not take mutexes because ownership/priority rules and blocking are incompatible with ISR context.
• Example use-case: Protecting a shared I2C bus driver state structure when multiple tasks issue sensor reads so only the owning task holds the bus.

Binary semaphore

• Ownership semantics: No strict owner; acts as an event/lock token. A task that gives can be different from the taker.
• Blocking behavior: Tasks block when semaphore count is 0; wake when given. Can be used for signaling or simple mutual exclusion.
• ISR safety: Usually safe to give from ISR (many RTOS provide an ISR-safe "give from ISR"); taking from ISR is not allowed if it blocks.
• Example use-case: ISR from a sensor data-ready pin gives the semaphore to a task that then processes the sample.

Counting semaphore

• Ownership semantics: No owner; maintains a count representing available resources or events.
• Blocking behavior: Tasks block when count is 0; each take decrements count. Multiple resources can be tracked.
• ISR safety: Safe to increment (give) from ISR in most RTOS; taking in ISR is not allowed if it would block.
• Example use-case: Limit concurrent access to a pool of DMA channels or track buffered sensor samples produced by ISR so a processing task can consume up to N samples.

Notes: Choose mutex when you need strict ownership and priority inheritance for avoiding priority inversion; use binary semaphores for signaling; counting semaphores for resource pools or event queues.

Scenario — sequence of events

• L (low) starts and acquires mutex protecting resource R.
• H (high) becomes runnable and immediately blocks trying to take the same mutex.
• Because H is blocked, scheduler runs next highest ready task: M (medium). M preempts L and runs for some time.
• L cannot run to release the mutex because M is running, so H remains blocked — this is priority inversion: H is indirectly blocked by M though M is lower priority than H.

How priority inheritance fixes it

• When H blocks on the mutex held by L, the RTOS temporarily raises L’s priority to H’s priority (L "inherits" H).
• Scheduler now prevents M from preempting L; L runs and releases the mutex sooner.
• Once L releases the mutex, its priority is restored and H acquires the mutex and proceeds. This bounds blocking time to the duration of L’s critical section.

When inheritance may not be enough

• Nested chains: L holds mutex A, M holds mutex B, H waits on A while another high-priority task waits on B — complex chains can still cause long blocking.
• Deadlock-like interactions and multiple resources where transitive blocking occurs.
• If inheritance is only ceilinged per mutex owner but tasks share many resources, worst-case blocking can still exceed deadlines.

Alternatives / stronger protocols

• Priority ceiling protocol (PCP) / Immediate Priority Ceiling Protocol (I-PCP): assign each mutex a ceiling equal to highest priority that may lock it; a task can lock only if its priority is higher than current system ceiling. Prevents deadlock and bounds blocking to one critical section.
• Stack Resource Policy (SRP): avoids dynamic ceiling checks by controlling task admission to system, used in sporadic servers.
• Design alternatives: minimize critical section length, use lock-free algorithms or non-blocking synchronization, reduce shared resource usage.

I would choose PCP or SRP for hard real-time guarantees; for simpler systems PI is often sufficient and inexpensive to implement in firmware RTOS kernels.

Approach (brief)
Use a circular buffer guarded by a mutex for mutual exclusion, and two counting semaphores: empty_slots and filled_slots. Producers wait on empty_slots then take mutex to push; consumers wait on filled_slots then take mutex to pop. Support optional timeouts by using semaphore take with timeout. From ISR, use the FromISR variants and request context switch if unblocked higher-priority task.

Pseudocode (FreeRTOS-style C)

#define BUF_SIZE 8
typedef struct {
  uint8_t data[BUF_SIZE];
  int head, tail;
  SemaphoreHandle_t mutex;         // binary semaphore / mutex
  SemaphoreHandle_t empty_slots;  // counting semaphore
  SemaphoreHandle_t filled_slots; // counting semaphore
} BoundedBuffer;

void buffer_init(BoundedBuffer *b) {
  b->head = b->tail = 0;
  b->mutex = xSemaphoreCreateMutex();
  b->empty_slots = xSemaphoreCreateCounting(BUF_SIZE, BUF_SIZE);
  b->filled_slots = xSemaphoreCreateCounting(BUF_SIZE, 0);
}

bool produce(BoundedBuffer *b, uint8_t item, TickType_t timeout) {
  // wait for an empty slot, with optional timeout
  if (xSemaphoreTake(b->empty_slots, timeout) != pdTRUE) return false; // timeout
  xSemaphoreTake(b->mutex, portMAX_DELAY);
  b->data[b->head] = item;
  b->head = (b->head + 1) % BUF_SIZE;
  xSemaphoreGive(b->mutex);
  xSemaphoreGive(b->filled_slots);
  return true;
}

bool consume(BoundedBuffer *b, uint8_t *item, TickType_t timeout) {
  if (xSemaphoreTake(b->filled_slots, timeout) != pdTRUE) return false; // timeout
  xSemaphoreTake(b->mutex, portMAX_DELAY);
  *item = b->data[b->tail];
  b->tail = (b->tail + 1) % BUF_SIZE;
  xSemaphoreGive(b->mutex);
  xSemaphoreGive(b->empty_slots);
  return true;
}

// From ISR: push one item if slot available (non-blocking)
// Returns true if item queued and a context switch may be requested via *pxHigherPriorityTaskWoken
bool produce_from_isr(BoundedBuffer *b, uint8_t item, BaseType_t *pxHigherPriorityTaskWoken) {
  // Try to decrement empty_slots without blocking
  if (xSemaphoreTakeFromISR(b->empty_slots, pxHigherPriorityTaskWoken) != pdTRUE) return false;
  // Cannot take mutex from ISR; instead protect shared index with critical section
  taskENTER_CRITICAL_FROM_ISR();
  b->data[b->head] = item;
  b->head = (b->head + 1) % BUF_SIZE;
  taskEXIT_CRITICAL_FROM_ISR();
  xSemaphoreGiveFromISR(b->filled_slots, pxHigherPriorityTaskWoken);
  return true;
}

Notes / Constraints

• Do NOT call blocking APIs from ISR. Use FromISR variants and non-blocking semantics.
• Mutexes (normal recursive mutex) cannot be used in ISR; use critical sections or disable interrupts very briefly when modifying indices.
• Timeouts: pass portMAX_DELAY for indefinite block (ensure configALLOW_UNPRIVILEGED or blocking allowed).
• Ensure semaphores initialized correctly; check for NULL.
• If multiple producers/consumers, semaphores provide ordering but not strict fairness — consider priority inheritance on mutex if needed.