Subject
atomic-waker is a no_std-compatible Rust crate exposing a single public type, AtomicWaker: a multi-consumer / single-producer cell that stores a core::task::Waker and lets one thread register a waker while other threads race to consume and wake it. The implementation is the extraction of futures::task::AtomicWaker into a standalone crate, used by smol-rs and the wider async ecosystem as a building block for cross-task notification.
Methodology
The published crate was downloaded from crates.io and unpacked into contents/; the upstream Git repository at the commit recorded in .cargo_vcs_info.json was checked out into vcs/ for cross-comparison. The published tree was compared against the upstream tree with diff -r, and the single source file (src/lib.rs, ~440 lines), the integration test (tests/basic.rs), the criterion benchmark (benches/waker.rs), and the CI configuration in .github/workflows/ were read in full. The lock protocol used to gate UnsafeCell access was walked through against the inline commentary, and the memory orderings on every compare_exchange, swap, fetch_or, and fetch_and were checked against the documented acquire/release contract.
Results
The published crate matches the upstream Git tree byte-for-byte across all source, test, and bench files; the only differences are cargo's standard normalisation of Cargo.toml and the auto-generated .cargo_vcs_info.json. The original manifest is preserved as Cargo.toml.orig.
The crate ships no binary artefacts (justifying has-binaries), no build.rs, and is not a proc-macro crate (justifying has-build-exec and has-install-exec). It is #![no_std] and pulls in no IO, networking, process, or cryptographic surface (justifying uses-network, uses-filesystem, uses-environment, uses-exec, uses-jit, uses-interpreter, uses-crypto). The crate implements no parser, interpreter, JIT, protocol, data structure, algorithm, or cryptographic primitive (justifying impl-parser, impl-interpreter, impl-jit, impl-protocol, impl-datastructure, impl-algorithm, and impl-crypto). It also does not itself spawn threads or drive an executor (justifying uses-concurrency); it is the implemented primitive that callers use to coordinate cross-thread wakeups.
The single optional runtime dependency, portable-atomic (a polyfill for targets without native atomics), is gated behind a feature and not default-on. dev-dependencies (criterion, futures, rayon) are not shipped to consumers.
The crate's central concern is the soundness of two unsafe blocks (justifying uses-unsafe) accessing an UnsafeCell<Option<Waker>> (src/lib.rs:292-350 and 403-412) plus the unsafe impl Send / unsafe impl Sync at src/lib.rs:442-443. Soundness rests on a two-bit lock encoded in an AtomicUsize: REGISTERING (0b01) is taken by the writer in register, WAKING (0b10) is taken by readers in take / wake. The transitions and their acquire/release orderings are documented in the long block comment at src/lib.rs:118-211 and were validated against the implementation. The race window where wake arrives while register holds the lock is closed by the REGISTERING|WAKING fallback branch in register (src/lib.rs:323-348), which swaps the state back to WAITING under AcqRel and drives the wake itself, so no notification is lost. CI runs cargo miri test with -Zmiri-strict-provenance and randomised layout on every push, which exercises the existing test under Miri's data-race detector. Together this supports unsafe-safe, unsafe-documented, unsafe-minimal, unsafe-tested, concurrency-impl-safe, concurrency-impl-correct, and concurrency-impl-documented.
The package ships one integration test (tests/basic.rs) but no unit tests inside src/lib.rs, no fuzz/ directory, and no property-based tests — justifying has-unit-tests, has-fuzz-tests, and has-property-tests. Two low-severity quality findings were recorded. FINDING-1 notes that the two rustdoc examples on AtomicWaker import AtomicWaker from futures::task rather than from this crate, so cargo test --doc does not exercise the audited code — the examples remain semantically valid since this crate is the extraction of that very type. FINDING-2 notes that tests/basic.rs is a single-scenario smoke test with no concurrent-register coverage, no property tests, no fuzz tests, and no loom model-checking; this is why the concurrency-impl-tested claim was not asserted. Miri coverage of the one existing test partially mitigates the gap but does not exercise the REGISTERING|WAKING fallback path. Nothing in the audit indicated malicious intent, supporting is-benign.
Conclusion
atomic-waker is a small, focused, no_std synchronization primitive with a well-documented lock protocol, minimal and contained unsafe usage, and Miri-checked CI. The implementation is sound under review. The only findings are low-severity quality observations about documentation examples and the breadth of the test suite for a concurrency primitive; neither affects real-world safety of the crate.