RTEMS | Add RTEMS API wrapper for "cpukit/score/.../cpu.h: Implement _CPU_Spin_wait()"? (#5650)

[Wayne Thornton (@wmthornton-dev)]

Wayne Thornton commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5650#note_154724


Ok, after reviewing the options, I have come to the following conclusions:

When developers implement lock-free ring buffers, sequence locks, or custom RCU algorithms across cores using C11 `<stdatomic.h>`, standard C provides the memory ordering models, but neither C11 nor POSIX defines an instruction-level pipeline throttle for the spin-wait loop itself. Without that throttle, tight CAS or token-polling loops flood the MESI interconnect with continuous read requests, actively degrading the performance of the thread trying to release the lock. This is obviously a problem and the entire reason _CPU_Spin_wait() was introduced.

Regarding finding an existing home within the current APIs that avoids creating a new `rtems_cpu_xxx` namespace, I think the SMP manager (`<rtems/smp.h>`) is the perfect fit for this.

Proposed Directive: 

```
/* Appropriate Doxygen comments would be placed here */
static inline void rtems_smp_spin_wait( void )
{
  _CPU_Spin_wait();
}
```

The physical benefits of pipeline throttling (mitigating cache-line bouncing, reducing interconnect saturation, and yielding ALU resources on SMT cores) are inherently SMP things. By placing the directive in `<rtems/smp.h>` it would live naturally alongside `rtems_smp_get_current_processor()` and `rtems_smp_processor_id()`.

There would also be zero overhead introduced by defining `rtems_smp_spin_wait()` as a static inline wrapper around `_CPU_Spin_wait()` in `<rtems/smp.h>`. Applications would get portable pipeline throttling with zero function-call overhead in their inner loops.

On uniprocessor builds, `_CPU_Spin_wait()` seamlessly degrades to `RTEMS_COMPILER_MEMORY_BARRIER()`, ensuring that ISR-to-thread polling loops in shared memory maintain compiler visibility without incurring hardware penalties.

The other option I can find is to place the directive in the task manager (`<rtems/rtems/tasks.h>`), but I don't know that this is an option I would prefer.

Proposed Directive:

```
/* Appropriate Doxygen comments would be placed here */
static inline void rtems_task_spin_wait( void )
{
  _CPU_Spin_wait();
}
```

Since tasks are the entities executing user-level polling loops, positioning it in the task manager makes it universally visible to all application developers regardless of whether they are thinking about SMP topology.

This however is a risk since directives in the task manager typically imply operating system state transitions or kernel-level scheduling interventions (`rtems_task_wake_after`, `rtems_task_suspend`). A static inline hardware hint that does not trap into the executive might feel structurally out of place among scheduling directives and potentially lead to confusion from developers.

I cannot find any other _valid_ locations that I believe such a directive would be appropriate.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5650#note_154724
You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/sent_notifications/4-7dndv674drmxg2mqebitofv8j-1d/unsubscribe | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | Help: https://gitlab.rtems.org/help


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260716/40ba3454/attachment-0001.htm>