arch_atomic: support nx atomic function

[zyfeier]

Summary

Modify the kernel to use nx atomic interfaces, avoiding the use of sizeof or typeof to determine the type of atomic operations, thereby simplifying the kernel's atomic interface operations.

This PR addresses the following issues:

1. It can resolve the issue of incorrect type retrieval when using sizeof；
2. It can resolve the issue of incorrectly using unsigned integers with atomic operations.

Impact

atomic function

Testing

sim:citest citest pass
sabre-6qaud:smp ostest pass
avr32dev1:nsh
bl602evb/elf
esp32-devkitc:sotest
esp32-devkitc:wamr_wasi_debug
mps3-an547/clang

[nuttxpr]

[Experimental Bot, please feedback here]

No, this PR description does not adequately meet the NuttX requirements. While it provides a basic summary of the change, it lacks crucial details and context. Here's a breakdown of what's missing and how it can be improved:

Summary:

• Insufficient Detail: "Modify the kernel to use only the long type atomic interfaces" is vague. Which atomic interfaces are being modified? Are all atomic operations now using long, or just a specific subset? What was the previous behavior? Be specific. For example: "Replace the use of atomic_add() with size-specific variants (e.g., atomic_add_long()) throughout the kernel to avoid ambiguity and improve type safety."
• Missing Rationale: Why is this change necessary? What problem does it solve? Does it improve performance, portability, or code clarity? For example: "Using sizeof or typeof to determine atomic operation types can lead to subtle errors when porting to different architectures or when dealing with complex data structures. This change enforces the use of explicit type specifiers, improving code maintainability and preventing potential portability issues."

Impact:

• Too Brief: "atomic function" is not helpful. Address all impact categories explicitly, even if the answer is "NO." Provide explanations where needed.
  • User Impact: Likely NO. But explain why. "No direct user impact is expected. This change is internal to the kernel and should not affect application behavior."
  • Build Impact: Possibly YES. If the change affects header files or build configurations, describe the impact. If NO, state so explicitly.
  • Hardware Impact: Possibly YES if this affects architecture-specific code. Specify which architectures are affected and how. If NO, explain why.
  • Documentation Impact: Possibly YES if any documentation needs updating to reflect the API changes.
  • Security Impact: Possibly YES or NO. Justify your answer. Does this change address any potential vulnerabilities or introduce new ones?
  • Compatibility Impact: Possibly YES or NO. Does this break any existing code or drivers? Does it affect compatibility with different NuttX versions?

Testing:

• Insufficient Detail: Provide more context. What does "sim:citest pass" mean? Which tests were run? "sabre-6qaud:smp pass" is also insufficient. Which SMP tests specifically?
• Missing Before/After Logs: Include actual log snippets demonstrating the change in behavior or performance, if applicable. Even if there's no visible functional change in the logs, provide some evidence that the code is functioning as expected (e.g., kernel boot log snippets).
• Expand on Test Setup: What specific configuration options were used for the build? What commands were used to run the tests? This information allows others to reproduce your results. Mention the NuttX version you tested against.

Example of an improved summary:

This PR refactors the kernel's atomic operations to exclusively use long type interfaces (e.g., atomic_add_long()). Previously, the code relied on sizeof and typeof to determine the appropriate atomic operation type, which could lead to portability issues and subtle errors when dealing with complex data structures. This change enforces the use of explicit type specifiers, improving code clarity, maintainability, and portability across different architectures. This change addresses issue #[insert issue number].

By providing more detail and context in each section, you make it easier for reviewers to understand the purpose, impact, and correctness of your changes, which significantly increases the chances of your PR being accepted.

[yamt]

• it seems a bit wasteful to mechanically replace short with long to me. especially where structure fields are arranged for a short.
• why long? i suspect it's simpler to use a fixed sized type like int32_t given the current usage in our tree.

[zyfeier]

• it seems a bit wasteful to mechanically replace short with long to me. especially where structure fields are arranged for a short.
• why long? i suspect it's simpler to use a fixed sized type like int32_t given the current usage in our tree.

Hi, yamt, we will implement an interface similar to linux/atomic/atomic-instrumented.h for use by the NuttX kernel. What are your suggestions?

[yamt]

• it seems a bit wasteful to mechanically replace short with long to me. especially where structure fields are arranged for a short.
• why long? i suspect it's simpler to use a fixed sized type like int32_t given the current usage in our tree.

Hi, yamt, we will implement an interface similar to linux/atomic/atomic-instrumented.h for use by the NuttX kernel. What are your suggestions?

similar in which sense?
instrumentation?
types? (atomic_t/atomic64_t/atomic_long_t)
something else?

[zyfeier]

similar in which sense?
instrumentation?
types? (atomic_t/atomic64_t/atomic_long_t)
something else?

@yamt only support int32_t atomic type and interface.

[pussuw]

• it seems a bit wasteful to mechanically replace short with long to me. especially where structure fields are arranged for a short.

  • why long? i suspect it's simpler to use a fixed sized type like int32_t given the current usage in our tree.

Some architectures do not support subword atomics without involving libatomic (RISC-V is one). As a fallback, the current code we have invokes the nx_atomic functions which use spin locks internally to guarantee data integrity which causes a huge performance impact. I already see this after this patch #14465.

If the data type size needs to be optimized, please make it possible for the user to force use of lock free versions (i.e. toolchain optimized versions) of the atomic_ procedures, as people who use them most likely want performance rather than size optimization.

EDIT:
I misread a bit and my rant is about using subword size types for atomics. Using int32 as the atomic type is fine.

[yamt]

similar in which sense?
instrumentation?
types? (atomic_t/atomic64_t/atomic_long_t)
something else?

@yamt only support int32_t atomic type and interface.

i have a bit concern about the size increase from "short", especially where it doesn't really need to be atomic. (eg. non-SMP)