For functions returning nothing, there is no need to document
with @return, as Doxgen complains about "documented empty
return type of ...".
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
With this change, `atomic_t` is 32-bit for 32-bit architectures
and 64-bit for 64-bit architectures. More specifically,
`sizeof(atomic_t) == sizeof(long)`.
Fixes#39530
Signed-off-by: Christopher Friedt <chrisfriedt@gmail.com>
For non-specified archs, including those out-of-tree, the possibility to
use a specific implementation has been reintroduced.
CONFIG_ATOMIC_OPERATIONS_ARCH must be selected to utilize this.
Signed-off-by: Tommie Skriver <tosk@demant.com>
There's a typedef for non-pointer values compatible with atomic
non-pointer objects. Add a similar typedef for pointer values, and
the corresponding macro for initializing atomic pointer types.
This also will simplify replacing the Zephyr atomic API with one
based on C11 atomics, should that be desirable. C11 atomic pointer
values are not void*.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Predefine ATOMIC_DEFINE in the Doxyfile so that documentation output is
generated correctly. In order to simplify the predefinition
ATOMIC_BITMAP_SIZE has been introduced.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Usually, GCC builtin or arch-specific atomic functions are being
used. The corresponding kconfigs are "selected" by architecture
or SoC kconfigs. CONFIG_ATOMIC_OPERATIONS_C is usually used to
override the GCC built-in or arch-specific atomic functions when
these two are not supported. So change the priority of #include
so that C version is included first if selected, and skips
the inline versions of the other two variants. Or else there
will be two compiled versions of atomic functions: inline version
and the compiled C version. Note that the arch-specific version
and builtin are swapped, so the builtin one is now the default.
Fixes#33857
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The xtensa atomics layer was written with hand-coded assembly that had
to be called as functions. That's needlessly slow, given that the low
level primitives are a two-instruction sequence. Ideally the compiler
should see this as an inline to permit it to better optimize around
the needed barriers.
There was also a bug with the atomic_cas function, which had a loop
internally instead of returning the old value synchronously on a
failed swap. That's benign right now because our existing spin lock
does nothing but retry it in a tight loop anyway, but it's incorrect
per spec and would have caused a contention hang with more elaborate
algorithms (for example a spinlock with backoff semantics).
Remove the old implementation and replace with a much smaller inline C
one based on just two assembly primitives.
This patch also contains a little bit of refactoring to address the
scheme has been split out into a separate header for each, and the
ATOMIC_OPERATIONS_CUSTOM kconfig has been renamed to
ATOMIC_OPERATIONS_ARCH to better capture what it means.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Both operands of an operator in the arithmetic conversions
performed shall have the same essential type category.
Changes are related to converting the integer constants to the
unsigned integer constants
Signed-off-by: Aastha Grover <aastha.grover@intel.com>
Consistently place C++ use of extern "C" after all include directives,
within the negative branch of _ASMLANGUAGE if used.
The inclusion of the generated syscall files is placed outside the
extern "C" block as the generated file has its own extern "C" block.
Background from issue #17997:
Declarations that use C linkage should be placed within extern "C"
so the language linkage is correct when the header is included by
a C++ compiler.
Similarly #include directives should be outside the extern "C" to
ensure the language-specific default linkage is applied to any
declarations provided by the included header.
See: https://en.cppreference.com/w/cpp/language/language_linkage
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
move atomic.h to sys/atomic.h and
create a shim for backward-compatibility.
No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.
Related to #16539
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
