Analyzing Acquire-Release Memory Ordering on Weakly Ordered Processors

First, separate the three levels of reasoning

Memory-ordering discussions become confusing when code, compiler behavior, CPU behavior, and devices are all mixed together. For interview traces, begin by identifying the level being tested.

1. C11/C++ atomics: The source language defines what executions are allowed. Acquire and release constrain compiler transformations and cause the compiler to generate suitable CPU ordering instructions where needed.

2. Linux kernel primitives: smp_store_release() and smp_load_acquire() express a comparable publish/consume pattern under the Linux Kernel Memory Model. They are not merely syntax variants of C11 atomics, but the reasoning shape is familiar.

3. Raw hardware litmus tests: These show direct loads, stores, and explicit barriers, with no compiler involved. On ARM, independent accesses to normal memory may be observed in a different order from program order unless dependencies or barriers constrain them.

For a driver interview, state your assumption explicitly:

“I am treating this as a data-race-free C11 atomic trace”
or
“This is an assembly-level ARM trace, so I am reasoning about CPU ordering rather than C undefined behavior.”

That distinction matters. A trace using plain shared C variables concurrently is not a useful C11 memory-order puzzle: it is normally a data race and therefore undefined behavior.

The minimal model: local order, coherence, and conditional synchronization

Here is the essential acquire-release model.

A release store prevents earlier operations in its own thread from being published after that store. An acquire load prevents later operations in its own thread from being performed as if they occurred before that load.

But those local constraints become a cross-thread guarantee only under one condition:

The acquire load must read the value written by the release store, or by its applicable release sequence, on the same atomic object.

When that happens:

The middle arrow is the important one: synchronizes-with. The full chain creates happens-before.

In contrast, these do not create a synchronization edge:

• A release store to ready and an acquire load from some unrelated status.
• An acquire load that reads an older value, such as the initial zero.
• A release and acquire merely appearing somewhere in the same program without the acquire observing that release.

The following Linux-kernel documentation is worth reading now because it states the two directional guarantees precisely, then applies them to a compact two-task trace.

The kernel notation in that example maps conceptually to the source-level pattern you used last lesson:

READ_ONCE() and WRITE_ONCE() suppress problematic compiler transformations; by themselves, they do not provide the required CPU ordering on weakly ordered systems. The acquire or release operation carries that ordering role.

A trace-analysis procedure you can use under pressure

For each trace, use the same sequence.

1. Record the initial state and label operations

Assume the shared variables start at zero unless the problem says otherwise. Label each load result and each relevant store:

• $W_x(1)$: write 1 to x
• $R_y=0$: read 0 from y
• $S_{\mathrm{rel}}(flag=1)$: release-store 1
• $L_{\mathrm{acq}}(flag)=1$: acquire-load observing 1

This keeps a multithreaded listing from becoming visually ambiguous.

2. Add each thread’s program-order constraints

Within a thread, source operations have a local sequence. For acquire/release reasoning, focus on the side each operation constrains:

• Before a release store: operations are on the published side.
• After an acquire load: operations are on the consuming side.

3. Ask what each load read from

This is the decisive step. A load reading the initial value does not synchronize with a later release store. A load reading a release-written value does.

4. Draw happens-before only where justified

Do not draw a release-to-acquire arrow because the operations have compatible names. Draw it only when the acquire reads the relevant release value.

5. Test the proposed outcome against those edges

An outcome is forbidden if it requires a read to observe an older value even though the write of the newer value happens-before that read.

A useful verbal conclusion is:

“This outcome is forbidden because the acquire reads the release-published flag, so the payload store happens-before the payload load.”

Or, for a permitted result:

“This outcome is allowed because neither acquire load observes the other thread’s release store. There is no cross-variable synchronization edge and no single global order imposed by acquire-release.”

Trace 1: publication forbids “new flag, old payload”

Consider the one-shot message publication pattern in C11 form:

#include <stdatomic.h>

int payload = 0;
atomic_int ready = 0;

/* Producer */
payload = 42;
atomic_store_explicit(&ready, 1, memory_order_release);

/* Consumer */
int r = atomic_load_explicit(&ready, memory_order_acquire);
int v = -1;

if (r == 1)
    v = payload;

The consumer can report either of these meaningful results:

The forbidden outcome is the one interviewers often want:

The reasoning is a chain, not an intuition about “cache flushing”:

1. payload = 42 is sequenced before the release store to ready.
2. The acquire load reads 1 from that release store.
3. Therefore, the release store synchronizes-with the acquire load.
4. The acquire load is sequenced before v = payload.
5. Therefore, payload = 42 happens-before the read of payload.
6. The read cannot legally produce the old 0.

This says nothing about a literal instant when all caches suddenly contain 42. It is a guarantee about the execution the program is allowed to observe.

The barrier-direction image below is a useful visual mnemonic. It classifies ordering directions such as LoadLoad and StoreStore. For this lesson, use it conceptually: an acquire constrains accesses after the observation, while a release constrains accesses before publication. The exact instructions emitted differ across ARM, x86, and other targets.

Trace 2: acquire-release is not a global sequential order

Now consider two separate atomic variables, initially zero.

atomic_int x = 0;
atomic_int y = 0;

/* Thread 0 */
atomic_store_explicit(&x, 1, memory_order_release);
int r0 = atomic_load_explicit(&y, memory_order_acquire);

/* Thread 1 */
atomic_store_explicit(&y, 1, memory_order_release);
int r1 = atomic_load_explicit(&x, memory_order_acquire);

The result to analyze is:

This outcome is permitted with acquire-release atomics, including on weakly ordered architectures.

Why?

• Thread 0’s acquire load reads the initial 0 from y, not Thread 1’s release-store of 1.
• Thread 1’s acquire load reads the initial 0 from x, not Thread 0’s release-store of 1.
• Therefore, neither acquire observes the other release.
• Without either synchronizes-with edge, there is no cross-thread happens-before relationship linking these operations.

Each atomic object is still coherent: all observers agree on a valid order of modifications to x, and likewise to y. What acquire-release does not impose is a single total order spanning both x and y.

The complete set of result pairs is permitted here:

The surprising row is $r0=0,r1=0$. Both threads can perform their store locally while their subsequent load still observes the old value of the other location. This is commonly called the store-buffering litmus test.

The same 0, 0 outcome is forbidden if all four operations are sequentially consistent atomics, because sequential consistency adds a single global total order for the atomic operations. It is not forbidden merely because each operation is acquire or release.

This is a key correction to an oversimplified slogan:

Acquire-release is strong enough for directed publication through a chosen synchronization variable. It is not a request that all threads agree on one global timeline for all atomic variables.

The programming-language memory-model reading presents exactly this distinction, beginning with acquire-release as a release-observed-by-acquire relationship and then using the store-buffering test to contrast it with sequential consistency.

Why a branch is not an acquire operation

This mistake is particularly relevant in firmware mailbox code:

while (flag == 0) {
    /* poll */
}

value = mailbox_data;

A source-level branch saying “only read data after flag is nonzero” does not, by itself, force a weakly ordered CPU to treat the data read as ordered after the flag read. The compiler and CPU need an explicit synchronization operation or a genuine dependency that the architecture recognizes.

At the C11 level, express the required operation directly:

while (atomic_load_explicit(&flag, memory_order_acquire) == 0) {
    /* poll */
}

value = mailbox_data;

At the Linux-kernel level, the analogous pattern is generally an acquire load of the flag followed by the payload access.

At raw ARM assembly level, ordering may require an appropriate barrier or acquire-load instruction. The following short segment shows the same issue through a polled mailbox: the producer must not expose the flag before the payload, and the consumer must not allow the payload read to move ahead of observing the flag.

For your Zephyr and Linux driver work, the transfer of ownership is usually more elaborate than a one-bit mailbox: a descriptor index, buffer address, ownership bit, and interrupt or event may all be involved. The same reasoning still applies. Find the object that signals ownership transfer, publish descriptor contents before releasing that object, and acquire it before dereferencing the descriptor.

A compact interview drill framework

When shown a trace, avoid beginning with “ARM can reorder anything” or “acquire-release makes it safe.” Both are too broad. Instead, use this structure:

1. State the initial values.
   “x and y begin at zero.”

2. Identify every atomic object and memory order.
   “x and y are distinct atomic objects; each store is release and each load is acquire.”

3. Find reads-from relationships.
   “For the proposed 0,0 result, each acquire reads the initialization, not the other thread’s release.”

4. Establish—or reject—synchronization edges.
   “Because no acquire reads a release-written value, no synchronizes-with edge exists.”

5. Conclude at the right strength.
   “The outcome is permitted under acquire-release. It would be excluded by sequential consistency’s global atomic order.”

For a publication trace, the corresponding response is:

“The acquire reads the release-published flag, so the producer’s preceding payload writes happen-before the consumer’s later payload read. A new flag with an old payload is forbidden.”

Avoid two common incorrect claims:

• “Acquire always sees the newest value.”
  No. An acquire constrains what follows if it observes a relevant release. It does not mean “read the latest write across the system.”

• “Release flushes memory globally.”
  No. Release establishes an ordering/publishing relationship; it is not a universal cache-management command and does not solve device DMA visibility or MMIO ordering.

Those device-specific questions are deliberately separate; the module’s final lesson will distinguish CPU memory ordering from cache coherency and device-I/O barriers.

Key takeaways

• Analyze traces by determining what each load reads from, not by looking only at the words “acquire” and “release.”
• A release store and an acquire load establish a cross-thread happens-before edge only when the acquire observes that release on the same synchronization object.
• In a proper publication trace, observing the published flag forbids observing an older associated payload.
• Acquire-release provides per-location coherence and directed publication; it does not impose one global order across separate atomic variables.
• Therefore, the store-buffering outcome where both threads read 0 is permitted with acquire-release atomics, but not with sequentially consistent atomics.
• A control-flow branch on a flag is not a replacement for an acquire operation on weakly ordered hardware.

Next, you will move from analyzing atomic traces to choosing the right synchronization primitive—mutex, spinlock, semaphore, completion/event, or atomic operation—for thread and interrupt-context scenarios.