#atomic #cell #sync #generic #trait

no-std radium

Portable interfaces for maybe-atomic types

11 unstable releases (5 breaking)

0.6.1 Nov 21, 2020
0.6.0 Oct 26, 2020
0.5.3 Oct 8, 2020
0.5.1 Sep 25, 2020
0.1.1 May 26, 2019

#17 in Concurrency

Download history 17923/week @ 2020-08-07 17974/week @ 2020-08-14 17139/week @ 2020-08-21 16796/week @ 2020-08-28 19013/week @ 2020-09-04 18885/week @ 2020-09-11 20766/week @ 2020-09-18 22315/week @ 2020-09-25 22119/week @ 2020-10-02 22669/week @ 2020-10-09 23510/week @ 2020-10-16 31068/week @ 2020-10-23 30264/week @ 2020-10-30 32324/week @ 2020-11-06 45906/week @ 2020-11-13 46786/week @ 2020-11-20

108,876 downloads per month
Used in 481 crates (via bitvec)

MIT license

45KB
649 lines

radium

Latest Version Documentation

radium provides abstractions and graceful degradation for behavior that must be shared-mutable, but merely may use atomic instructions to do so.

The primary export is the Radium trait. This is implemented on all symbols in the atomic module, and on their Cell<T> equivalents, and presents the atomic inherent API as a trait. Your code can be generic over Radium, use a stable and consistent API, and permit callers to select atomic or Cell behavior as they need.

The symbols in the atomic module are conditionally present according to the target architecture’s atomic support. As such, code that is portable across targets with varying atomic support cannot use those names directly. Instead, the radium::types module provides names that will always exist, and forward to the corresponding atomic type when it exists and the equivalent Cell<T> type when it does not.

As the cfg(target_has_atomic) compiler attribute is unstable, radium provides the macro radium::if_atomic! to perform conditional compilation based on atomic availability.

This crate is #![no_std]-compatible, and uses no non-core types.

Target Architecture Compatibility

Because the compiler does not expose this information to libraries, radium uses a build script to detect the target architecture and emit its own directives that mark the presence or absence of an atomic integer. We accomplish this by reading the compiler’s target information records and copying the information directly into the build script.

If radium does not work for your architecture, please update the build script to handle your target string and submit a pull request. We write the build script on an as-needed basis; it is not proactively filled with all of the information listed in the compiler.


@kneecaw - https://twitter.com/kneecaw/status/1132695060812849154

Feelin' lazy: Has someone already written a helper trait abstracting operations over AtomicUsize and Cell<usize> for generic code which may not care about atomicity?

@ManishEarth - https://twitter.com/ManishEarth/status/1132706585300496384

no but call the crate radium

(since people didn't care that it was radioactive and used it in everything)

No runtime deps