About atomic operations on Cortex-A (no MMU)

Embedded
1

I have MMU disabled while doing some tests on atomics. Here's what I have:

Case 1:

static VAR: AtomicBool = AtomicBool::new(false);
VAR.compare_and_swap(false, true, Ordering::AcqRel);

It assembles into

  58:	52800028 	mov	w8, #0x1                   	// #1
  5c:	90000009 	adrp	x9, 0x0
  60:	91098129 	add	x9, x9, #0x260
  64:	085ffd2a 	ldaxrb	w10, [x9]
  68:	350000ca 	cbnz	w10, 0x80
  6c:	080afd28 	stlxrb	w10, w8, [x9]
  70:	35ffffaa 	cbnz	w10, 0x64
  . . .
  80:	d5033f5f 	clrex
  . . .

Case 2:

static VAR: AtomicBool = AtomicBool::new(false);
VAR.swap(true, Ordering::AcqRel);

It assembles into

  58:	52800028 	mov	w8, #0x1                   	// #1
  5c:	90000009 	adrp	x9, 0x0
  60:	91094129 	add	x9, x9, #0x260
  64:	085ffd3f 	ldaxrb	wzr, [x9]
  68:	080afd28 	stlxrb	w10, w8, [x9]
  6c:	35ffffca 	cbnz	w10, 0x64
  . . .

What I expected is both cases will not work when MMU is not enabled. However, only swap() doesn't work and generates exception. Code after compare_and_swap() runs fine: I see my LED turns on. Moreover, I thought maybe write operation just fails, or gets skipped, or whatever... but consecutive load() acquires true from the variable.

Also, I do not completely understand compare_and_swap() description:

Notice that even when using AcqRel , the operation might fail and hence just perform an Acquire load, but not have Release semantics.

It can fail and stay in acquired state? Will it freeze in some infinite loop waiting for release then or what will happen in this case? Could anyone please explain me what is happening and why?

2

I do not know anything about your embedded device, but I can explain the compare_and_swap documentation.

The compare_and_swap operation will fail if the current parameter does not match the actual value. In this case, the atomic has only performed a load, so since Release only make sense for stores, the failed operation would not have Release semantics. It will not freeze or otherwise wait in any situation; compare_and_swap always returns immediately.

3

Ah, device is Raspberry Pi 4, in AArch64 exec state

4

Hi,
I only have experience there with a Rapberry Pi 3 and there all atomic operations leading to ldaxrb or strxrb operations and the like just freezes the Pi3 if MMU and cache is disabled. May be this has changed a bit on PI4. You may want to ask this specific question in the raspberry bare metal forum if you like: Forum

1 Like
5

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.