These reviews are from cargo-vet. To add your review, set up cargo-vet and submit your URL to its registry.

The current version of AtomicRefCell is 0.1.13.

cargo-vet does not verify reviewers' identity. You have to fully trust the source the audits are from.

safe-to-deploy (implies safe-to-run)

This crate will not introduce a serious security vulnerability to production software exposed to untrusted input. More…

safe-to-run
Implied by other criteria

This crate can be compiled, run, and tested on a local workstation or in controlled automation without surprising consequences. More…


These reviews are from Crev, a distributed system for code reviews. To add your review, set up cargo-crev.

The current version of AtomicRefCell is 0.1.13.

0.1.7 (older version) Rating: Neutral Thoroughness: Medium Understanding: Medium

by yvt on 2021-09-18

Basically std::sync::RwLock with panicking instead of blocking.

AtomicRefCell uses atomic operations to manipulate the variable containing the borrow state. Overall, the usage of atomic operations looks correct.

Minor issue

The bounds for AtomicRefCell<T>: Send are unnecessarily restrictive.

AtomicRefCell aborts the program if a large number of immutable borrow attempts are made while it's mutably borrowed. While a code comment claims this is "very unlikely to happen in a real program", this can cause a problem in a program that uses AtomicRefCell in a way unintended by atomic_refcell's authors and runs on a 32-bit target architecture. spin::RwLock doesn't have this problem.

0.1.5 (older version) Rating: Positive Thoroughness: Medium Understanding: Medium

by vorner on 2019-11-19

It mostly looks to do what it says and seems well written. The previous issue resolved.

0.1.4 (older version) Rating: Positive Thoroughness: Medium Understanding: Medium

by vorner on 2019-11-01

Show review…

It mostly looks to do what it says and seems well written.

There's one concern about possible UB, though one that's unlikely to have any practical effect.


Crates in the crates.io registry are tarball snapshots uploaded by crates' publishers. The registry is not using crates' git repositories. There is absolutely no guarantee that the repository URL declared by the crate belongs to the crate, or that the code in the repository is the code inside the published tarball. To review the actual code of the crate, it's best to use cargo crev open atomic_refcell. Alternatively, you can download the tarball of atomic_refcell v0.1.13 or view the source online.