Senior Embedded Developer Interview Preparation Guide - FAANG Standards

Recommendation: fixed-priority preemptive scheduling, rate-monotonic order, proved by response-time analysis

For a certified flight computer I would choose fixed-priority scheduling (certified here means approved by an aviation authority, typically against DO-178C, the standard for airborne software, so the timing argument is part of the evidence package). Each task gets a constant priority, shorter period meaning higher priority (rate-monotonic assignment; deadline-monotonic is the same idea ordered by shortest deadline, used when deadlines are shorter than periods), and the scheduler always runs the highest-priority ready task. Earliest-deadline-first (EDF) instead gives each job a priority from its absolute deadline (fixed when the job is released), so the highest priority goes to whichever ready job has the earliest deadline and priorities change from job to job. EDF is better on paper: it can schedule any single-processor set of independent, preemptible tasks with deadlines equal to periods and total utilisation up to 100 percent, whereas rate-monotonic scheduling is only guaranteed up to n(2^(1/n) - 1), which is about 69.3 percent as the number of tasks n grows. I would still not choose it here, because a certification authority does not ask which policy packs the CPU best. It asks whether you can show, with evidence, that every deadline is met, and what happens when something goes wrong.

The argument to the certifier

1. The analysis is exact and reproducible. Response-time analysis computes each task's worst-case response R by iterating R = C + sum over higher-priority tasks of ceil(R / Tj) x Cj until it stops changing (C is the worst-case execution time, Tj the period of a higher-priority task). A reviewer can redo it by hand from the table of C and T values, and it is a necessary and sufficient test for fixed priorities when deadlines equal periods (necessary and sufficient: a set passes if and only if it is schedulable, with no pessimism). For the health task (C = 17, T = 80) with the four faster tasks above it: R = 17; then 17 + ceil(17/5) x 1 + ceil(17/10) x 2 + ceil(17/20) x 4 + ceil(17/40) x 6 = 17 + 4 + 4 + 4 + 6 = 35; then 17 + 7 + 8 + 8 + 6 = 46; and the iteration continues 61, 72, 76, 77, 77. It stops at 77, below 80, so the task passes. This is the shape of the response-time table a timing report hands to the certifier. This kind of analysis supports the timing-margin evidence DO-178C asks for (DO-178C objective 6.3.4.f, on source code being accurate and consistent, includes worst-case execution timing among the things reviews and analyses address; whichever method you use, measured times need an argument that the worst case was actually exercised, and the compiler, linker and hardware effects on those times need to be accounted for).
2. Utilisation is not the question. The 69.3 percent bound is sufficient, not necessary (a set under it is safe, but a set over it may still be schedulable). The code below uses harmonic periods (each period divides the next), which flight loops often have. The set has total utilisation 0.9625, far above the 0.7435 bound for five tasks, and still passes the exact test.
3. Overload stays local. Priorities are a contract: apart from the blocking term in item 5, a high-priority task is never delayed by a lower one, so a late or overrunning task damages only itself and the tasks below it. Under EDF the set is at 96 percent utilisation with no slack, so the extra time an overrunning job takes comes straight out of every other job's margin; and once the overrunning job's own deadline has passed it is still ahead of every job released later (its deadline is earlier than theirs), so well-behaved tasks start missing too. The simulation below shows both.
4. It matches existing practice and structure. ARINC 653, the avionics partitioning standard, uses a fixed cyclic schedule of time windows for partitions (isolated applications, each given guaranteed slices of processor time and its own protected memory) and, inside each window, preemptive fixed-priority scheduling of processes. Using fixed priorities inside a partition follows that structure.
5. Locking has a proven bound. With the priority ceiling protocol, a task is blocked at most once, by at most one critical section of a lower-priority task, and deadlock is impossible (Sha, Rajkumar and Lehoczky, 1990). That blocking time is added to the analysis as a term B.

The exact test and the overload comparison, as code

The task set: five tasks, periods 5, 10, 20, 40 and 80 ms with worst-case execution times 1, 2, 4, 6 and 17 ms. The script computes the utilisation, both bounds, the exact response times, and a discrete-time simulation (1 tick is 0.1 ms) in which the third job of one task overruns by the stated amount. The simulator builds one job per release (release time, absolute deadline, remaining work, priority). On each tick it runs the ready job with the best key (smallest priority number for fixed priority, earliest deadline for EDF) and removes one tick of its work. A deadline miss is recorded when a job is still unfinished at its deadline tick and again if it later completes late, so the set() at the end removes the duplicate and each miss counts once. The overrun is injected by adding extra_ms to the job with k == 2, the third release of the named task. Run in a python:3.12-slim container with python fp_vs_edf.py:

from math import ceil

# (name, C, T) in ms; deadline = period; harmonic periods, as flight loops often are
tasks = [("attitude", 1.0, 5), ("actuators", 2.0, 10), ("nav", 4.0, 20),
         ("guidance", 6.0, 40), ("health", 17.0, 80)]
n = len(tasks)
U = sum(C / T for _, C, T in tasks)
print(f"U = {U:.4f}   RMS bound n(2^(1/n)-1) = {n * (2 ** (1 / n) - 1):.4f}   EDF bound = 1")

# exact fixed-priority test: response-time analysis, rate-monotonic order
for i, (name, C, T) in enumerate(tasks):
    R = C
    while True:
        R2 = C + sum(ceil(R / Tj) * Cj for _, Cj, Tj in tasks[:i])
        if R2 == R or R2 > T:
            break
        R = R2
    print(f"  {name:9s} R = {R2:5.1f} ms  deadline {T:3d} ms  {'ok' if R2 <= T else 'MISS'}")

# discrete-time preemptive simulator, 1 tick = 0.1 ms, one overrun injected
TICK = 10
def simulate(policy, overrun_task, extra_ms, horizon_ms=160):
    jobs, misses = [], []
    for name, C, T in tasks:
        for k in range(int(horizon_ms // T)):
            c = round(C * TICK) + (round(extra_ms * TICK) if (name == overrun_task and k == 2) else 0)
            jobs.append({"task": name, "rel": k * T * TICK, "dl": (k + 1) * T * TICK, "left": c,
                         "prio": [t[0] for t in tasks].index(name)})
    for now in range(horizon_ms * TICK):
        ready = [j for j in jobs if j["rel"] <= now and j["left"] > 0]
        if ready:
            key = (lambda j: j["dl"]) if policy == "EDF" else (lambda j: j["prio"])
            j = min(ready, key=lambda j: (key(j), j["rel"]))
            j["left"] -= 1
            if j["left"] == 0 and now + 1 > j["dl"]:
                misses.append((j["task"], j["dl"] // TICK))
        for j in ready:
            if now + 1 == j["dl"] and j["left"] > 0:
                misses.append((j["task"], j["dl"] // TICK))
    return sorted(set(misses), key=lambda m: (m[1], m[0]))

from collections import Counter
for who, extra in (("guidance", 14), ("nav", 12)):
    for policy in ("FP", "EDF"):
        m = Counter(task for task, _ in simulate(policy, who, extra))
        print(f"{who} job overruns by {extra} ms, {policy}: missed deadlines per task = {dict(m)}")

U = 0.9625   RMS bound n(2^(1/n)-1) = 0.7435   EDF bound = 1
  attitude  R =   1.0 ms  deadline   5 ms  ok
  actuators R =   3.0 ms  deadline  10 ms  ok
  nav       R =   8.0 ms  deadline  20 ms  ok
  guidance  R =  18.0 ms  deadline  40 ms  ok
  health    R =  77.0 ms  deadline  80 ms  ok
guidance job overruns by 14 ms, FP: missed deadlines per task = {'guidance': 1, 'health': 1}
guidance job overruns by 14 ms, EDF: missed deadlines per task = {'actuators': 2, 'attitude': 2, 'nav': 2, 'guidance': 1}
nav job overruns by 12 ms, FP: missed deadlines per task = {'nav': 1, 'guidance': 1, 'health': 2}
nav job overruns by 12 ms, EDF: missed deadlines per task = {'actuators': 4, 'attitude': 6, 'nav': 3, 'guidance': 1}

Reading it: every task passes the exact test, and the slowest (health) has only 3 ms of margin (77 against 80), so the set is schedulable but tight. When guidance overruns by 14 ms, fixed priority loses one guidance deadline and one health deadline (the task below it) while attitude, actuators and nav are untouched. EDF loses deadlines in four tasks (attitude, actuators, nav and guidance), including attitude and actuators, which did nothing wrong. In this simulation a late job keeps running to completion, and each missed deadline is counted once.

What the answer leaves out unless you add it

The test above assumes no blocking, no release jitter and zero context-switch cost. A real submission adds B for shared resources (ceiling protocol), release jitter from interrupts, the cost of each switch and timer interrupt, and worst-case execution times with margin from a justified method. It also adds budget enforcement (a run-time guard): a timer that stops a task at its allotted worst case, so an overrun becomes a detected fault rather than a silent delay.

What would change the choice

Choose EDF if the task set cannot be made schedulable under rate-monotonic or deadline-monotonic priorities even with the exact test (for instance non-harmonic periods near full utilisation and no way to shed load), and pair it with budget enforcement so that the overload behaviour is bounded. Also consider a time-triggered (fully static cyclic) schedule if the certifier wants every execution order fixed in advance; it gives the simplest evidence at the price of flexibility.

I’d design the cadence around what leadership actually needs: trend, risk, and decisions: not daily implementation detail.

Format:

• A short weekly summary email or doc
• A simple status signal: green / yellow / red
• Three bullets on progress, risks, and next steps
• A clear section for decisions or help needed

How I keep it lightweight:
I’d pull from a team-owned dashboard or a brief async update, so I’m not creating extra reporting work. If the project is moving quickly, I’d report changes at the theme level: what moved materially since last week, what risks increased or decreased, and whether delivery confidence changed.

Worked example
For instance, in a week where a checkout-redesign initiative is underway, the summary might read: "Theme: payments migration. Status: green, holding steady. This week: data migration for the new payment provider completed and passed validation, one day ahead of plan. Risk: the fraud-model retraining depends on two weeks of live traffic on the new UI, which pushes that milestone to the 24th; this was already reflected in the plan so confidence is unchanged. Decision needed: none this week." That's specific enough for leadership to see real progress without a blow-by-blow of daily standups.

What leadership gets:

• Are we on track?
• What changed?
• What decisions or support are needed?

What the team avoids:

• Daily status meetings just for reporting
• Rewriting the same information in multiple places

That balance keeps executives informed while protecting the team’s execution time.

Approach (brief)

Use the standard bit-twiddling trick: find the rightmost non-trailing zero, flip it, clear bits to its right, then insert (count_ones-1) ones at the least-significant positions. This is O(1) with few bit ops.

C implementation

#include <stdint.h>

// Return next higher uint32 with same popcount, or 0 if none exists.
uint32_t next_with_same_ones(uint32_t x) {
    if (x == 0) return 0;
    uint32_t smallest = x & -x;            // rightmost 1
    uint32_t ripple = x + smallest;        // flip rightmost non-trailing zero
    if (ripple == 0) return 0;             // overflow -> no larger number
    uint32_t ones = x ^ ripple;            // bits that changed
    ones = (ones >> 2) / smallest;         // shift the ones to the rightmost positions
    return ripple | ones;
}

Why it works

• smallest = isolate lowest 1.
• ripple adds smallest giving the next carry to flip the zero above the trailing ones.
• ones computes the trailing ones that need to be packed at LSB side.
• Division by smallest and shift align the ones.

Complexity & edge cases

• Time: O(1) constant bit operations. Space: O(1).
• Returns 0 on overflow (no higher with same popcount) and for input 0.

Notes

• Works on two's-complement; well-suited for embedded C.

The mediocre version of this answer says "it depends on the situation" and lists factors without a rule connecting them. A strong answer gives an actual decision rule you apply, not just a list of considerations.

Framework: Expected Value of Information (EVI) versus the cost and time to collect it, adjusted by reversibility and risk tolerance.

• EVI: roughly, how much would knowing this information change your decision, multiplied by how much a wrong decision would cost. If more information wouldn't change what you'd do, its value is close to zero no matter how uncertain you feel.
• Cost and time to collect: what it actually costs, in calendar time and effort, to get the information, not just whether it's theoretically obtainable.
• Reversibility: a "two-way door" decision, cheap to undo, tolerates acting on less information than a "one-way door" decision that's expensive or impossible to undo.
• Risk tolerance: how much downside the team or organization can absorb if the decision turns out wrong, a business input, not a personal preference.

Decision rule: gather more information only if the EVI plausibly exceeds the cost and time to collect it, AND the decision is not cheaply reversible. If either condition fails, act now with monitoring when the decision is reversible or low-stakes. When the ambiguity carries legal, safety, or compliance exposure you're not positioned to resolve alone, escalate rather than choosing between act and wait, a genuine third option a two-option framing misses.

Concrete stop-iterating thresholds, so "gather more" doesn't drift into permanent research mode:

• A confidence-interval-width threshold: stop waiting once the CI (confidence interval, the range the true result plausibly falls within) around the key metric narrows below a threshold that matters, for example a lift estimate narrower than 5 percentage points.
• An elapsed-time cap: a hard stop, for example 4 weeks, after which you decide with what you have, because the cost of delay is itself a cost of being wrong.
• A cost-of-being-wrong ceiling: if the maximum plausible downside of acting now and being wrong is smaller than the cost of an additional week of waiting, act now.

Worked example, low-traffic experiment: a product manager is testing a new onboarding flow, but traffic is low. After 2 weeks, only 340 total conversions have accumulated, and the estimated lift is +6%, with a CI of roughly -9% to +21%, far too wide to call. EVI is genuinely high here (the flow ships to 100% of new users if it wins, undoing a bad first impression has real cost), so more information has real value. But waiting is not free either; every extra week costs a cohort of users a possibly-worse experience. Applying the concrete thresholds: stop waiting when the CI narrows below plus or minus 5 points, OR 4 weeks elapse, OR the cost of remaining uncertainty exceeds the cost of running the test one more week. At week 4, the CI still hasn't narrowed enough and the elapsed-time cap triggers, so the flow ships to the marginally better variant, with monitoring in place, rather than waiting indefinitely for statistical certainty that low traffic may never deliver.

A related, everyday framing for lower-stakes calls, useful when there's no time to build a full EVI estimate: ask whether the downside of proceeding now is harmful (irreversible, for example data loss or a broken production system with no rollback) or merely beneficial-if-avoided (inconvenient but recoverable, for example a change that's easy to roll back). If the downside is genuinely harmful and irreversible, postpone and gather more information even under time pressure. If it's merely inconvenient and reversible, proceed and monitor.

Escalation as a third option: sometimes the missing information isn't something you can generate yourself at all, for example when the ambiguity is about whether an action is legally or contractually permissible. There, the choice isn't act now versus gather more data, it's escalate to the people equipped to resolve it, such as legal or compliance, because no amount of your own analysis substitutes for their read.

A different-discipline version, briefly. A site reliability engineer deciding whether to keep collecting more telemetry before committing to a root-cause theory mid-incident runs the same rule: would more diagnostic data actually change the mitigation chosen (EVI), how long would that take to collect versus the cost of the outage continuing (cost and time), is the mitigation itself a two-way door like a feature-flag rollback or a one-way door like a schema migration (reversibility), and how much customer-facing downtime can the team absorb before acting anyway (risk tolerance) -- with the same escalation option, paging a specialist, when the ambiguity is outside what the on-call engineer is positioned to resolve alone.

Purpose & typical usage
I use JTAG and SWD to debug, program, and recover embedded targets. JTAG is a 4/5-pin boundary-scan/debug protocol used on many cores; SWD is a 2-pin ARM alternative optimized for Cortex-M (smaller pin count, faster setup).

Primary signals

• JTAG: TCK = clock, TMS = state machine control, TDI = data in, TDO = data out (TRST optional).
• SWD: SWCLK = clock, SWDIO = bidirectional data line (protocol encodes read/write/ack).

Typical workflow

• Connection checks: verify Vtarget present, measure Vref, continuity of ground, correct pin mapping, basic target power and reset lines. Confirm adapter recognized by host (lsusb/OpenOCD/J-Link).

Using a tool

• Halt core: connect with OpenOCD / J-Link GDB server and issue halt (or "monitor halt"); SWD/JTAG sequence pauses CPU via debug halt request.
• Read/write registers & memory: use GDB info registers, monitor mdw (OpenOCD) or J-Link RTT/Commands; use gdb memory read/write or OpenOCD mdb/mww.
• Load firmware: use load in GDB or OpenOCD program <file> verify reset or J-Link JLinkExe/GUI to flash.
• Recover hung device: assert reset line or use power-cycle; use debug reset-halt sequences (connect under reset) or enable flash mass-erase via tool (useful if SWD pins are reconfigured). Lauterbach/J-Link support “connect under reset” and mass erase.

Tools
OpenOCD (configurable, free), Segger J-Link (fast, robust, commercial/debugger), Lauterbach TRACE32 (high-end, expensive). I prefer J-Link for routine dev, OpenOCD for CI and flexibility.

Notes
Always try connect-under-reset if normal attach fails; check for SWD pin remapping or low-power modes that disable debug.

Requirements & goals

• Exactly-once semantics for telemetry uploads
• Minimize flash writes (append-only, batching, compact metadata)
• Enable server-side deduplication (content-hash)
• Recover from crashes without server duplicates

Identifiers & sequencing

• Each telemetry record gets a 64-bit monotonic local sequence number (LSN).
• Each upload batch gets a Batch ID = {first_LSN, last_LSN, batch_nonce, timestamp}.
• Each record also stores a 64-bit content-hash (e.g., SHA-1 or CRC64 for speed + optional SHA256) used by server dedupe.

Local journal layout (flash-friendly)

• Append-only circular journal in flash pages. Journal entry = {LSN, content-hash, offset/len or small payload}. Store payload inline up to X KB; otherwise store payload in data area and journal stores pointer.
• Write-only appends minimize erase cycles. Use page-sized writes and coalesce multiple records into one physical write where possible.
• Keep a small in-RAM write buffer: accumulate up to N records or T ms before flushing one page write (batching).

Batching strategy

• Form batches by either: max_records (e.g., 50) or max_size (e.g., 64 KB) or timeout (100 ms), whichever first.
• When flushing a batch to flash, write a single compact batch header containing first_LSN, last_LSN, count, CRC, and an index into payload region — single-page commit where possible.

Upload protocol

1. Client builds HTTP/gRPC POST with: Batch ID, [LSN, content-hash] list, compressed payloads.
2. Server computes dedupe by content-hash and returns ACK with:
   • accepted_LSN_range (e.g., up to last_accepted_LSN)
   • per-record status bitmap (accepted/duplicate/reject) or list of accepted hashes
   • server_commit_token (monotonic per-device)

Retransmission rules

• Retransmit until server ACKs batch as committed. Use exponential backoff with jitter.
• If network fails mid-upload, retry same Batch ID (idempotent). Server uses Batch ID + device id to detect duplicate batch and resolve using content-hash.
• Only remove journal entries after receiving server_commit_token that covers those LSNs.

Exactly-once & deduplication

• Server de-duplicates by content-hash; for exactly-once semantics, server must be able to detect duplicate batches via Batch ID and idempotency store (small per-device bitmap or last_seen LSN ranges). Server responds with which LSNs it accepted or which hashes already existed.
• Client uses server response to delete only confirmed LSNs from journal.

Crash recovery

• On boot, read highest persisted LSN and last fully flushed batch headers.
• Query server with "resume request": provide device id, highest_server_token seen (if any), and list of outstanding Batch IDs or LSN ranges (compact using ranges or bloom filter of hashes if many).
• Server replies which LSNs it already has (by Batch ID or content-hash) and returns current server_commit_token.
• Client resumes retransmit only for unacknowledged LSNs. Because server dedupes by content-hash and remembers Batch IDs, retransmits never create duplicates.

Flash GC & compaction

• Periodically erase/compact pages by removing journal entries with LSN <= confirmed_LSN. Use wear-leveling and avoid small random writes.
• When deleting, mark whole page obsolete then erase; keep a small free pool.

Safety checks

• Robust CRC/sequence checks on journal entries.
• Limit journal size with backpressure: if journal full, stop sensor collection or drop low-priority telemetry.

Why this works

• Append-only + batched page writes reduces write amplification.
• LSN + Batch ID + server commit token plus content-hash gives deterministic idempotence; server-side dedupe ensures retransmits are safe.
• Crash recovery uses compact summaries so device only resends missing items, preventing duplicates.

Direct answer

For a cryptographic primitive I do not yet know well, working competence means I can reason about its threat model and misuse resistance, not just call its interface correctly, and what convinces me my understanding is correct rather than merely plausible is validating it against known-answer test vectors and getting independent review, not just watching it round-trip successfully on my own test data. I refuse to put anything I have only recently learned in front of real user data without both, and I say so explicitly rather than quietly shipping it on my own authority.

Structured elaboration

Learning it properly

• Start from the primitive's threat model and intended use, not just its interface: what guarantees does it actually provide, confidentiality, integrity, or both, and what is it explicitly not designed to protect against.
• Learn the library's specific misuse-resistance properties and footguns: whether it defaults to a safe mode, whether it silently allows a dangerous configuration such as a reused nonce or a skipped authentication-tag check, since library-specific misuse is a more common real-world failure than the underlying algorithm being broken.
• Understand key lifecycle end to end: generation, storage, rotation, and destruction, not just how a key is passed into an encryption call.

Confirming the understanding is actually correct

• Validate against known-answer test vectors from a trusted source, a standards body or the primitive's own published reference vectors, which prove the implementation matches the specification, rather than relying on the fact that it round-trips, encrypts and decrypts back to the original text, since a round trip alone proves almost nothing about whether the implementation is actually secure or standards-compliant.
• Check side-channel and constant-time behavior where relevant, whether comparison of a tag or a key happens in constant time, since a functionally correct but timing-leaky implementation can still be broken.
• Get independent review from someone who already works in this area before treating the understanding as solid enough to act on; self-review in an area this specialized reliably misses exactly the class of mistake that matters most.

Knowing what to refuse

• Explicitly decide what will not ship on your own authority: rolling your own primitive instead of using a reviewed one, making a judgment call about an unfamiliar mode's security properties without review, or shipping under deadline pressure with a known validation gap.
• Prefer deferring to reviewed primitives instead of your own fresh understanding whenever the option exists; correctness here is about restraint as much as skill.

Worked example

Needed to add authenticated encryption, encryption that protects both confidentiality and integrity so tampered ciphertext is detected rather than silently decrypted into garbage, to a service using a library never used before, under a deadline to close a real security defect. I started by reading not the interface reference first but the library's own guidance on safe defaults and known misuse patterns, specifically around nonce handling, since nonce reuse is one of the most common ways this class of primitive gets broken in practice even when the underlying algorithm is sound. Before trusting the implementation, I ran it against the primitive's published known-answer test vectors and confirmed the outputs matched exactly, rather than relying on the fact that encrypting and then decrypting a test string round-tripped correctly, since a round trip only proves the encrypt and decrypt calls agree with each other, not that either one matches the specification: a broken implementation that silently ignored or mishandled the nonce parameter could still round-trip a single test string perfectly while failing known-answer vectors that vary the nonce and check the exact expected ciphertext, which is the failure mode a round trip cannot see at all. I verified that tag comparison in the library used a constant-time comparison rather than a plain equality check, since a naive comparison there can leak timing information usable to forge a valid tag. I got a colleague with prior cryptography review experience to look specifically at the key management path before merging, and was explicit about which parts I was least confident in. I declined to also implement a second, less common mode the ticket mentioned as a stretch goal, on the grounds that shipping one well-validated mode under deadline was safer than rushing two, and said so directly to the requester rather than quietly cutting the corner.

Trade-offs and pitfalls

• Treating a successful encrypt-decrypt round trip as proof of correctness is the single most dangerous shortcut here, since it verifies almost nothing about the security properties that actually matter.
• Rolling a personal implementation of an unfamiliar primitive, instead of using an existing, reviewed library, trades a small amount of flexibility for a large, usually invisible increase in risk.
• Skipping independent review under deadline pressure is exactly the failure mode this discipline exists to prevent; a self-confident but unreviewed understanding of a new primitive is not the same as a validated one.
• Deferring everything indefinitely, never learning enough to contribute, is also a failure mode; the goal is calibrated confidence backed by evidence, not permanent caution.

Overview (brief)
As an embedded developer I choose topology based on power, latency, reliability and maintenance trade-offs. Below are concise comparisons of star, tree and mesh topologies for IoT sensor networks.

Star

• Description: All nodes talk directly to a central hub/gateway.

• Advantages:

  • Scalability: simple for small to moderate node counts.
  • Latency: low (single hop).
  • Power: low on endpoints (short transmissions).
  • Maintenance: easy (single point to monitor).

• Disadvantages:

  • Reliability: single point of failure at hub.
  • Scalability: hub becomes bottleneck at large scale.
  • Power: hub requires higher capacity.

• Use case: Battery-powered environmental sensors in a building reporting to a nearby gateway.

Tree

• Description: Hierarchical multi-hop (parent/child routing).
• Advantages:
  • Scalability: better than star over area.
  • Power: leaf nodes can sleep; intermediate nodes handle routing.
  • Maintenance: organized structure simplifies diagnostics.
• Disadvantages:
  • Reliability: parent node failure isolates subtree.
  • Latency: increases with depth.
• Use case: Campus lighting control where structured routing reduces wiring.

Mesh

• Description: Many-to-many multi-hop with dynamic routing (e.g., Zigbee, Thread).
• Advantages:
  • Reliability: high (redundant paths).
  • Scalability: good—adds nodes to extend coverage.
  • Latency: variable but can be optimized with routing.
• Disadvantages:
  • Power: routing nodes consume more energy (not ideal for deep-sleep endpoints).
  • Maintenance: more complex firmware and OTA management.
• Use case: Industrial sensor mesh where reliability and self-healing are critical.

Decision rule: Use star for simplicity and low-latency small deployments; tree for structured coverage with modest complexity; mesh when redundancy and resilience outweigh power/maintenance costs.

Sizing first. A buddy allocator (every block has an order: its size is 2 to the power of its order bytes, so order 5 is 32 bytes and order 16 is 65,536 bytes; it splits a block into two equal halves, "buddies", and merges two free halves back) only deals in power-of-two block sizes. On a device with 128 KB of RAM in total, the allocator cannot own all of it: the stack, .data, .bss and the allocator's own bookkeeping have to fit too. The design below manages a 64 KB arena (order 16), the largest power of two that leaves the other 64 KB for everything else, with 32-byte minimum blocks (order 5). Doubling the arena to 128 KB would not leave room for the bookkeeping. If more is needed, a second 32 KB arena (order 15, with a 1,024-byte state array) could be managed too, but the code below keeps its arena, state and list heads as file-scope statics, so it manages exactly one arena; a second one needs those moved into a struct that every call receives.

Representing free blocks. Three pieces of state, all static arrays (nothing comes from malloc):

1. free_head[order]: for each order 5 to 16, the index of the first free block of that size, or NIL.
2. Free blocks store their own list links. A free block is unused memory, so its first four bytes hold next and prev as 16-bit indices (the block's offset divided by 32). A doubly linked list gives O(1) removal of a specific buddy during coalescing, which a singly linked list cannot.
3. state[i]: one byte per 32-byte unit (2048 bytes for 64 KB). It is 0 for a unit inside a larger block, otherwise the block's order, with a flag bit saying free or allocated. This is what makes free(p) need no size argument and no header in front of the block, and it lets free check a buddy's state with one byte read.

Metadata cost, measured from the object file: 2048 bytes of state plus 34 bytes of list heads, about 3.2% of the 64 KB arena. A header-per-block design would pay on every block instead.

State byte examples. Suppose the arena is one free 64 KB block: state[0] is 0x8C (free flag 0x80 plus 12, which is order 16 - 5 + 1) and every other byte is 0. After one 32-byte allocation, state[0] is 0x01 (allocated, order 5), and the freed upper halves left behind are marked at units 1, 2, 4, 8, 16, 32, 64, 128, 256, 512 and 1024 with 0x81, 0x82, 0x83, up to 0x8B (free blocks of orders 5 to 15). A throwaway harness that includes buddy.c directly and prints the non-zero state bytes (it is not part of the test driver below) shows exactly these values right after buddy_init(), after that allocation and after the matching buddy_free: [0]=0x8C only, then [0]=0x01 with [1]=0x81, [2]=0x82, [4]=0x83, up to [1024]=0x8B, then [0]=0x8C only again. The test driver below checks behaviour and does not print them. A zero byte means "in the middle of a bigger block", so a pointer to the interior of a block is rejected. That only holds if a merge clears the state byte of the block being freed, not only that of the free buddy it absorbs (the code clears both; a stale byte left on the free buddy still has the free bit set, so a pointer to it is refused as a double free anyway): if the higher half were an allocated block being freed into a free lower buddy, its stale "allocated, order 5" byte would survive inside the merged block, and a later free of a pointer into the middle of that block would be taken for a real block and corrupt the free lists.

Why flipping one bit gives the buddy. Unit indices count 32-byte units. A block of order o covers 2^(o-5) units and starts at an index that is a multiple of 2^(o-5). Its buddy is the other half of the order o+1 block that contains it, and the two halves differ only in the bit worth 2^(o-5). Example at order 6 (64-byte blocks, 2 units each): the blocks start at indices 0, 2, 4, 6. Flipping bit 1 (the value 2) maps 4 to 6 and 6 to 4, so those are buddies (byte offsets 128 and 192), and 0 and 2 are buddies; index 2 and index 4 are neighbours but are not buddies, because merging them would not give an aligned 128-byte block. At order 5 the flip is bit 0: unit 5 and unit 4 are buddies. In the code that is idx ^ (1u << (o - MIN_ORDER)).

Trace of splitting down to 32 bytes and merging back. Start with one free 64 KB block at index 0. buddy_alloc(32) wants order 5, takes the order 16 block and halves it eleven times: the upper half of each step (indices 1024, 512, 256, ..., 2, 1) goes on the free list of orders 15, 14, ..., 5, and index 0 is returned. buddy_free then reads state[0] = 0x01, so order 5; the buddy at index 0 ^ 1 = 1 has state 0x81 (free, order 5), so they merge into an order 6 block at index 0; the buddy at 0 ^ 2 = 2 has state 0x82, merge again; and so on, eleven merges, until order 16, where the loop stops and the block goes back on the order 16 list (state[0] = 0x8C again, state[1] = 0).

Split and coalesce. On alloc(n): round n up to a power of two (at least 32), then search the lists from that order upward for the first non-empty one. Take its block and, while it is larger than needed, halve it: keep the lower half and push the upper half on the free list of the next lower order. On free(p): look up the block's order, then repeatedly compute the buddy's index by flipping one bit, idx ^ (1 << (order - 5)). If the buddy is a free block of the same order, remove it from its list, merge (the merged block starts at the lower index) and go up one order; otherwise stop and push the block. Both operations loop at most 11 times (orders 16 down to 5), so the work is bounded, which matters for interrupt latency.

Protecting critical sections. The free lists and state bytes are shared between threads and interrupt handlers, so every change to them must look atomic. A mutex cannot be taken inside an interrupt service routine (ISR, the handler the hardware runs when an interrupt fires), so the code masks interrupts around each allocator operation. On Cortex-M that means setting PRIMASK (a one-bit core register; while it is 1, all interrupts with configurable priority are held off; CMSIS describes __disable_irq as disabling IRQ interrupts by setting PRIMASK, and it needs privileged mode). The code first reads the old PRIMASK value and restores that value on exit, instead of unconditionally re-enabling: a call made from an ISR, or from a section that was already masked, then does not turn interrupts back on early. Interrupts stay masked for at most 11 split steps (in buddy_alloc) or 11 merge steps (in buddy_free), each of which is one list push or remove plus a state write. Counted from the arm-none-eabi-gcc 14.2.1 -mcpu=cortex-m3 -mthumb -Os listing (every instruction in an it block counted, whether or not its condition holds) and confirmed by tracing the worst case instruction by instruction in a QEMU Cortex-M3 model, the worst case is about 440 Thumb-2 instructions in buddy_alloc (11 empty-list checks of 6 instructions, one list_remove of 19, 11 splits of 29 instructions each, 19 of them in list_push) and about 525 in buddy_free (11 merge passes of about 43 instructions each, 19 of them in list_remove). That is an instruction count, not a time: loads, branches and flash wait states cost more than one cycle each, so the time has to be measured on the target. If a high-priority interrupt cannot tolerate even that, the alternative is to forbid allocation in ISRs entirely (they use a fixed-block pool and tasks use the buddy allocator under a mutex), and to measure the masked time on the target before deciding. buddy_free also rejects pointers outside the arena, misaligned pointers, interior pointers and double frees, because one bad free would otherwise corrupt a list silently.

The code. Run in a gcc:14 container (GCC 14.4, aarch64, with -O2 -Wall -Wextra -fsanitize=address,undefined). The interrupt masking is compiled in only for __arm__; the host build uses empty stubs, so this run tests the algorithm and not the masking.

#ifndef BUDDY_H
#define BUDDY_H
#include <stddef.h>

void  buddy_init(void);
void *buddy_alloc(size_t size);   /* NULL if no block is free */
void  buddy_free(void *p);        /* ignores NULL, rejects bad pointers */
size_t buddy_free_bytes(void);    /* for tests and diagnostics */
size_t buddy_block_size(size_t request); /* size actually reserved */

#endif

#include <stdint.h>
#include "buddy.h"

#define MIN_ORDER   5u                       /* 32-byte smallest block */
#define MAX_ORDER   16u                      /* 64 KB: the whole arena */
#define ARENA_SIZE  (1u << MAX_ORDER)
#define NUM_MIN     (ARENA_SIZE >> MIN_ORDER) /* 2048 smallest blocks */
#define NIL         0xFFFFu

/* ---- critical section: interrupts masked, previous state restored ---- */
#if defined(__arm__)
static inline uint32_t cs_enter(void) {
    uint32_t primask;
    __asm volatile("mrs %0, primask\n\tcpsid i" : "=r"(primask) :: "memory");
    return primask;
}
static inline void cs_exit(uint32_t primask) {
    __asm volatile("msr primask, %0" :: "r"(primask) : "memory");
}
#else
static inline uint32_t cs_enter(void) { return 0; }   /* host build: single thread */
static inline void cs_exit(uint32_t s) { (void)s; }
#endif

/* ---- storage: all static, nothing from malloc ---- */
static uint8_t arena[ARENA_SIZE] __attribute__((aligned(32)));

/* One byte per 32-byte unit. 0 = inside a larger block.
   Otherwise (order - MIN_ORDER + 1), with 0x80 set when the block is free. */
#define FREE_BIT 0x80u
static uint8_t state[NUM_MIN];

/* A free block holds its own list links, as unit indices (16 bits each). */
typedef struct { uint16_t next, prev; } node_t;
static uint16_t free_head[MAX_ORDER + 1];

static node_t *node_at(uint16_t idx) { return (node_t *)&arena[(size_t)idx << MIN_ORDER]; }

static void list_push(unsigned order, uint16_t idx) {
    node_t *n = node_at(idx);
    n->prev = NIL;
    n->next = free_head[order];
    if (n->next != NIL) node_at(n->next)->prev = idx;
    free_head[order] = idx;
    state[idx] = (uint8_t)(FREE_BIT | (order - MIN_ORDER + 1u));
}

static void list_remove(unsigned order, uint16_t idx) {
    node_t *n = node_at(idx);
    if (n->prev != NIL) node_at(n->prev)->next = n->next;
    else free_head[order] = n->next;
    if (n->next != NIL) node_at(n->next)->prev = n->prev;
}

void buddy_init(void) {
    for (unsigned i = 0; i < NUM_MIN; i++) state[i] = 0;
    for (unsigned o = 0; o <= MAX_ORDER; o++) free_head[o] = NIL;
    list_push(MAX_ORDER, 0);                  /* one free 64 KB block */
}

static unsigned order_for(size_t size) {
    unsigned o = MIN_ORDER;
    while (((size_t)1 << o) < size && o <= MAX_ORDER) o++;
    return o;                                  /* > MAX_ORDER means too big */
}

size_t buddy_block_size(size_t request) {
    unsigned o = order_for(request);
    return o > MAX_ORDER ? 0 : ((size_t)1 << o);
}

void *buddy_alloc(size_t size) {
    unsigned want = order_for(size ? size : 1);
    if (want > MAX_ORDER) return NULL;
    uint32_t s = cs_enter();
    unsigned o = want;
    while (o <= MAX_ORDER && free_head[o] == NIL) o++;     /* smallest free block that fits */
    if (o > MAX_ORDER) { cs_exit(s); return NULL; }
    uint16_t idx = free_head[o];
    list_remove(o, idx);
    while (o > want) {                                     /* split: keep low half, free the high half */
        o--;
        list_push(o, (uint16_t)(idx + (1u << (o - MIN_ORDER))));
    }
    state[idx] = (uint8_t)(want - MIN_ORDER + 1u);         /* allocated, not free */
    cs_exit(s);
    return &arena[(size_t)idx << MIN_ORDER];
}

void buddy_free(void *p) {
    if (p == NULL) return;
    uint8_t *b = (uint8_t *)p;
    if (b < arena || b >= arena + ARENA_SIZE) return;      /* not ours */
    size_t off = (size_t)(b - arena);
    if (off & ((1u << MIN_ORDER) - 1u)) return;            /* not a block start */
    uint16_t idx = (uint16_t)(off >> MIN_ORDER);
    uint32_t s = cs_enter();
    uint8_t st = state[idx];
    if (st == 0 || (st & FREE_BIT)) { cs_exit(s); return; } /* interior pointer or double free */
    unsigned o = (unsigned)(st & 0x7Fu) - 1u + MIN_ORDER;
    while (o < MAX_ORDER) {                                /* coalesce while the buddy is a free block of this order */
        uint16_t buddy = (uint16_t)(idx ^ (1u << (o - MIN_ORDER)));
        if (state[buddy] != (uint8_t)(FREE_BIT | (o - MIN_ORDER + 1u))) break;
        list_remove(o, buddy);
        state[buddy] = 0;                                  /* both halves become interior units of the merged block */
        state[idx] = 0;
        if (buddy < idx) idx = buddy;
        o++;
    }
    list_push(o, idx);
    cs_exit(s);
}

size_t buddy_free_bytes(void) {
    size_t total = 0;
    for (unsigned o = MIN_ORDER; o <= MAX_ORDER; o++)
        for (uint16_t i = free_head[o]; i != NIL; i = node_at(i)->next) total += (size_t)1 << o;
    return total;
}

In the test driver below, i * 2477 % n visits every index exactly once, because 2477 is odd and so shares no factor other than 1 with 2048 (they are coprime), so the frees happen in a scrambled but complete order. The driver takes every 32-byte block, frees them in a scrambled order, runs a seeded random alloc and free stress with a tag check on each block, tries bad frees, and finally tries three bad pointers on a live block that was formed by a merge (a pointer into its middle, a misaligned one, and an aligned one a full arena length away), checking that nothing was freed and the block's bytes are untouched:

#include <stdint.h>
#include <stdio.h>
#include <string.h>
#include "buddy.h"

static uint32_t rng_state = 12345u;
static uint32_t rng(void) { rng_state = rng_state * 1664525u + 1013904223u; return rng_state >> 8; }

#define MAXLIVE 3000
static void *live[MAXLIVE];
static size_t live_size[MAXLIVE];

int main(void) {
    buddy_init();
    printf("free at start: %zu bytes\n", buddy_free_bytes());
    printf("request 33 -> block %zu, request 32 -> block %zu, request 100 -> block %zu\n",
           buddy_block_size(33), buddy_block_size(32), buddy_block_size(100));

    /* 1. Take every 32-byte block, then free them in a scrambled order. */
    static void *all[2048];
    unsigned n = 0;
    while (n < 2048 && (all[n] = buddy_alloc(32)) != NULL) n++;
    printf("32-byte blocks handed out: %u, extra alloc returns %s\n", n, buddy_alloc(32) ? "pointer" : "NULL");
    for (unsigned i = 0; i < n; i++) {
        unsigned j = (unsigned)(i * 2477u) % n;            /* 2477 is odd, so coprime with 2048 */
        if (all[j]) { buddy_free(all[j]); all[j] = NULL; }
    }
    for (unsigned i = 0; i < n; i++) if (all[i]) buddy_free(all[i]);
    size_t free_now = buddy_free_bytes();
    void *whole = buddy_alloc(64 * 1024);
    printf("after freeing all: free=%zu, one 64 KB alloc %s\n", free_now, whole ? "succeeds" : "FAILS");
    buddy_free(whole);

    /* 2. Random stress: fill each block with a tag, verify the tag before freeing. */
    memset(live, 0, sizeof live);
    unsigned fails = 0, corrupt = 0;
    for (unsigned step = 0; step < 200000; step++) {
        unsigned slot = rng() % MAXLIVE;
        if (live[slot]) {
            uint8_t tag = (uint8_t)(slot & 0xFF);
            uint8_t *p = live[slot];
            for (size_t k = 0; k < live_size[slot]; k++) if (p[k] != tag) { corrupt++; break; }
            buddy_free(live[slot]);
            live[slot] = NULL;
        } else {
            size_t sz = 1 + rng() % 2000;
            live[slot] = buddy_alloc(sz);
            if (!live[slot]) { fails++; continue; }
            live_size[slot] = sz;
            memset(live[slot], (int)(slot & 0xFF), sz);
        }
    }
    for (unsigned i = 0; i < MAXLIVE; i++) buddy_free(live[i]);
    printf("stress: corrupted blocks = %u, failed allocs (arena full) > 0: %s\n", corrupt, fails ? "yes" : "no");
    printf("after stress and freeing everything: free=%zu\n", buddy_free_bytes());
    void *w2 = buddy_alloc(64 * 1024);
    printf("one 64 KB alloc %s\n", w2 ? "succeeds" : "FAILS");
    buddy_free(w2);

    /* 3. Bad frees are rejected. */
    void *a = buddy_alloc(64);
    buddy_free(a); buddy_free(a);                          /* double free: ignored */
    int local; buddy_free(&local);                         /* not from the arena: ignored */
    printf("free after double and foreign free: %zu\n", buddy_free_bytes());

    /* 4. A pointer into the middle of a live block, or a misaligned one, is rejected, even after merges. */
    void *x = buddy_alloc(32), *y = buddy_alloc(32);       /* units 0 and 1 */
    buddy_free(x); buddy_free(y);                          /* y merges into its lower buddy x */
    uint8_t *blk = buddy_alloc(64);                        /* the merged block, at unit 0 */
    memset(blk, 0xAB, 64);
    size_t before = buddy_free_bytes();
    buddy_free(blk + 32);                                  /* interior pointer: must be ignored */
    buddy_free(blk + 1);                                   /* not a block start: must be ignored */
    buddy_free((void *)((uintptr_t)blk + 65536u));         /* 32-byte aligned but one arena length away: must be ignored */
    int intact = 1;
    for (int k = 0; k < 64; k++) if (blk[k] != 0xAB) intact = 0;
    printf("interior, misaligned and out-of-arena frees ignored: %s, block contents intact: %s\n",
           before == buddy_free_bytes() ? "yes" : "NO", intact ? "yes" : "NO");
    buddy_free(blk);
    printf("free after those frees and the real free: %zu\n", buddy_free_bytes());
    return 0;
}

Output:

free at start: 65536 bytes
request 33 -> block 64, request 32 -> block 32, request 100 -> block 128
32-byte blocks handed out: 2048, extra alloc returns NULL
after freeing all: free=65536, one 64 KB alloc succeeds
stress: corrupted blocks = 0, failed allocs (arena full) > 0: yes
after stress and freeing everything: free=65536
one 64 KB alloc succeeds
free after double and foreign free: 65536
interior, misaligned and out-of-arena frees ignored: yes, block contents intact: yes
free after those frees and the real free: 65536

The "one 64 KB alloc succeeds" lines show that coalescing restored the single large block both after the scrambled frees and after the stress run. The last block of the driver is what proves the pointer checks work, and each check was removed in turn to confirm it: without the st == 0 test the run prints block contents intact: NO; without the alignment test it prints ignored: NO and intact: NO; without the arena-range test the plain output is unchanged but -fsanitize=undefined reports an out-of-bounds index into state. The earlier double-free and stack-pointer tests alone would not notice any of these. A silent list corruption would not show in buddy_free_bytes, which is why the block's own bytes are tagged and re-read. The same file compiled for Cortex-M3 with arm-none-eabi-gcc 14.2.1 -mcpu=cortex-m3 -mthumb -Os -c has a 540-byte .text, 67,648 bytes of .bss (the 65,536-byte arena, 2,048 bytes of state, 34 bytes of list heads and 30 bytes of padding that keep the arena 32-byte aligned) and contains two cpsid i instructions, one in buddy_alloc and one in buddy_free. That build was only compiled, not run on a target. At -Os GCC also turns the clearing loop in buddy_init into a call to memset (the object file lists memset as undefined), so a freestanding link must provide memset or the loop has to be written so the compiler cannot make that call.

Costs of the design. Internal fragmentation (space wasted inside a block): a 33-byte request occupies 64 bytes, wasting 31 bytes (48% of the block), and a 100-byte request takes a 128-byte block. The loss can approach half of a block, so choose this allocator when request sizes are mostly powers of two or when you want fast, header-free, coalescing allocation with a worst-case bound, and use fixed-size pools for the hot small sizes.

Priority inversion is a high-priority task being delayed by lower-priority work. Setup: preemptive fixed-priority scheduling on one CPU (a ready task, one that wants the CPU and is not waiting on anything, with the highest priority always runs, and it interrupts a lower-priority task mid-run). Priorities are H > M > L; in the numbers below L = 1, M = 2, H = 3, and a bigger number wins. A task is blocked when it is waiting for something, here a mutex, and so is not ready. Response time is the time from a task's arrival to its completion. A mutex is a lock with an owner; priority inheritance is the rule that a lock owner temporarily runs at the highest priority among the tasks it blocks.

The scenario in numbers (1 tick = 1 ms)

Convention used throughout: tick k is the millisecond from t = k to t = k + 1, so a task that "runs ticks 3 to 7" occupies the CPU from t = 3 until t = 8 and "finishes at t = 8". In the program output below, "released" means the moment the task arrived; it has nothing to do with unlocking the mutex.

• L arrives at 0: 1 ms of work, takes the mutex, 3 ms inside the critical section, unlocks, 1 ms more.
• H arrives at 2: 1 ms of work, locks the mutex, 1 ms in the critical section, unlocks, 1 ms more.
• M arrives at 3: 5 ms of work, never touches the mutex.

A Python simulation (a preemptive fixed-priority loop with one mutex) models it. Its code is below, and its output is the timeline, where each character is one millisecond:

# Preemptive fixed-priority scheduling, one CPU, one mutex, 1 tick = 1 ms.
# A bigger number is a higher priority. Program steps: ("w", ms) work, ("lock",), ("unlock",).
def simulate(inherit):
    tasks = {
        "L": dict(arrive=0, prio=1, prog=[["w", 1], ["lock"], ["w", 3], ["unlock"], ["w", 1]]),
        "H": dict(arrive=2, prio=3, prog=[["w", 1], ["lock"], ["w", 1], ["unlock"], ["w", 1]]),
        "M": dict(arrive=3, prio=2, prog=[["w", 5]]),
    }
    owner, waiting, timeline, finish = None, [], "", {}

    def eff(name):                       # effective priority
        p = tasks[name]["prio"]
        if inherit and owner == name and waiting:
            p = max([p] + [tasks[w]["prio"] for w in waiting])
        return p

    def ready():
        return [n for n, t in tasks.items() if t["arrive"] <= now and t["prog"] and n not in waiting]

    for now in range(40):
        while ready():                   # settle zero-time lock and unlock steps
            n = max(ready(), key=eff)
            step = tasks[n]["prog"][0]
            if step[0] == "lock":
                if owner is None:
                    owner = n; tasks[n]["prog"].pop(0)
                else:
                    waiting.append(n)    # blocked: not ready until the owner unlocks
            elif step[0] == "unlock":
                tasks[n]["prog"].pop(0); owner = None
                if waiting:              # hand the mutex to the highest-priority waiter
                    w = max(waiting, key=lambda x: tasks[x]["prio"])
                    waiting.remove(w); owner = w; tasks[w]["prog"].pop(0)
            else:
                break
        if not ready():
            break
        n = max(ready(), key=eff)
        tasks[n]["prog"][0][1] -= 1
        timeline += n
        if tasks[n]["prog"][0][1] == 0:
            tasks[n]["prog"].pop(0)
        if not tasks[n]["prog"]:
            finish[n] = now + 1
    return timeline, finish

for inherit in (False, True):
    line, fin = simulate(inherit)
    print("inheritance" if inherit else "no inheritance")
    print("  tick     :", "".join(str(i % 10) for i in range(len(line))))
    print("  running  :", line)
    print(f"  H finished at t = {fin['H']} ms; H released at 2 ms, so response time {fin['H'] - 2} ms; "
          f"M finished at {fin['M']}; L finished at {fin['L']}")

Run in a python:3.12-slim container it prints:

no inheritance
  tick     : 0123456789012
  running  : LLHMMMMMLLHHL
  H finished at t = 12 ms; H released at 2 ms, so response time 10 ms; M finished at 8; L finished at 13
inheritance
  tick     : 0123456789012
  running  : LLHLLHHMMMMML
  H finished at t = 7 ms; H released at 2 ms, so response time 5 ms; M finished at 12; L finished at 13

Without inheritance. L runs tick 0 and locks the mutex at t = 1; its 3 ms critical section would fill ticks 1 to 3 if nothing interrupted it, but H and M do interrupt it, so L gets only tick 1 of it now and the other 2 ms later. H arrives at t = 2 and preempts L (L holds the lock but is only "ready"), so H runs tick 2, which is its 1 ms of work before the lock. At t = 3 H tries to lock the mutex and blocks, because L owns it. The CPU now has two ready tasks, L (priority 1, still owing 2 ms of critical section) and M (priority 2, just arrived). M wins and runs ticks 3 to 7 (5 ms, finishing at t = 8). Only then does L get the CPU, runs ticks 8 and 9 to finish its critical section, and unlocks at t = 10. H gets the mutex and runs ticks 10 and 11 (1 ms in the critical section, 1 ms more) and finishes at t = 12, which is a response time of 12 - 2 = 10 ms. H was blocked from t = 3 to t = 10, 7 ms, for a lock whose critical section is 3 ms long, because M, which does not even use the lock, sat in between. That is the inversion: H, the highest priority, could not run because of L, and L could not run because of M, so M, the middle priority, effectively outranked H.

With inheritance. At t = 3 H blocks on a mutex owned by L, so L runs at H's priority (3). L now beats M and runs its remaining 2 ms (ticks 3 and 4), unlocks at t = 5, and the mutex goes straight to H, which runs ticks 5 and 6 and finishes at t = 7. L drops back to its own priority at the unlock. M runs afterwards (ticks 7 to 11, finishing at t = 12), and L finishes its last millisecond at t = 13. H's response time falls from 10 ms to 7 - 2 = 5 ms, and the blocking time (t = 3 to t = 5) is exactly L's remaining critical section (2 ms), not M's 5 ms. The price is paid by M, which now finishes at 12 ms instead of 8.

What limits the benefit

• H still waits for the critical section. Inheritance bounds the delay at the owner's remaining critical-section length; it does not remove it. Long sections mean long blocking.
• It needs an owner. A semaphore that any task may release has no owner to boost, so inheritance generally needs a mutex type that records its owner; check what your RTOS does for its semaphores before using one as a lock.
• Chains. If L is itself blocked on a second lock held by a lower task, the boost must propagate. POSIX specifies that inheritance applies recursively to other mutex owners, so a conforming implementation must propagate the boost along the chain.
• It is optional and per-lock. POSIX makes PTHREAD_PRIO_INHERIT an option, and you must request it per mutex (the default is PTHREAD_PRIO_NONE). A lock without the attribute has no protection.
• The owner must be runnable. If L is blocked on I/O or a resource that does not propagate priority, boosting L helps nothing.
• Not a deadlock cure, and it adds cost. It adds work on the contended lock and unlock path, and multiple locks can still produce chains of blocking.

I would verify an implementation by running exactly this task set on the target RTOS with and without the attribute and measuring H's worst response time.