std::atomic in µOS++

[armint]

Now that modern arm gcc for bare-metal includes an implementation of std::atomic I was wondering if µOS++ might benefit from the use of it in some locations. From what I've seen, std::atomic<uint32_t> is always lock free on cortex-M4 (not on cortex-M0 though) and I think some structures might benefit from it.

Also, I am curious how locking of the atomic library compares to the locking that µOS++ is currently using (e.g. disabling the interrupts below a pre-defined priority).

[ilg-ul]

std::atomic ... I was wondering if µOS++ might benefit from the use of it in some locations.

Without much thinking, I would say that µOS++ might benefit from the use of it in some locations, but I see two difficulties:

• to identify these locations
• to do it portably across all supported architectures

how locking of the atomic library compares to the locking that µOS++ is currently using (e.g. disabling the interrupts below a pre-defined priority).

This is a tough question, and I don't have an answer yet. Generally, by design, std:: atomic<> is intended for access to resources shared by multiple cores, while disabling interrupts is, of course, intended to protect some code from being interrupted in the middle of some actions that must be done uninterrupted.

However, my feeling is that not all these actions that must be done uninterrupted really need this, and some might be reworked to use std::atomic, but it is hard to tell now.

This will definitely require some thorough understanding of the atomic primitives, on both Arm and RISC-V devices.

There is also the question of performances in a multi-threaded environment, and how exactly the locks are implemented.

I did a quick test with:

std::atomic_int acnt;

main() {
  // ...
  ++acnt;
}

and the generated code for a Cortex-M7 looks like this:

     41e:	4b0e      	ldr	r3, [pc, #56]	; (458 <main+0x64>)
     420:	f3bf 8f5b 	dmb	ish
     424:	e853 1f00 	ldrex	r1, [r3]
     428:	3101      	adds	r1, #1
     42a:	e843 1200 	strex	r2, r1, [r3]
     42e:	2a00      	cmp	r2, #0
     430:	d1f8      	bne.n	424 <main+0x30>

which is a small busy wait loop to access the associated monitor. It might not be a big deal, and happen very rarely, but generally multi-threaded implementations should avoid busy waits, since they simply waste cycles.

I am open to any other thoughts on the subject.

[armint]

Hmm, the busy loop is an interesting side-effect I hadn't thought of. The importance of it compared to blocking interrupts will probably be application dependent.

[ilg-ul]

Of course, it depends how often it happens, but generally for me any busy loop is also a waste of power, and the whole µOS++ is trying to be as low power as possible.

[armint]

Also, from what I see the RISC-V toolchain is not there yet. Or does that depend on the specific RISC-V architecture? I have a small project for a ch32v003 microcontroller (RV32EC) and atomic is not implemented. When I use an atomic in that project I get a linker error:

/home/armin/.local/xPacks/@xpack-dev-tools/riscv-none-elf-gcc/12.2.0-3.1/.content/bin/../lib/gcc/riscv-none-elf/12.2.0/../../../../riscv-none-elf/bin/ld: CMakeFiles/wch32v003.elf.dir/src/main.cpp.obj: in function `std::__atomic_base<long>::operator++()':
/home/armin/.local/xPacks/@xpack-dev-tools/riscv-none-elf-gcc/12.2.0-3.1/.content/riscv-none-elf/include/c++/12.2.0/bits/atomic_base.h:385: undefined reference to `__atomic_fetch_add_4'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

[ilg-ul]

You need a core which implements the A extension.

I did a quick test with a RV32IMAC device; the build passed, the generated code is:

80000248:	0008c797          	auipc	a5,0x8c
8000024c:	bfc78793          	addi	a5,a5,-1028 # 8008be44 <acnt>
80000250:	4705                	li	a4,1
80000252:	0f50000f          	fence	iorw,ow
80000256:	04e7a02f          	amoadd.w.aq	zero,a4,(a5)

FYI, in Eclipse I added some project templates that can generate all kind of Cortex & RISC-V projects, and immediately run them with QEMU.