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
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
