#atomic

no-std atomic-memcpy

Byte-wise atomic memcpy

5 releases

0.2.0 Aug 3, 2022
0.1.3 Feb 26, 2022
0.0.0 Jan 29, 2022

#166 in Concurrency

Download history 5/week @ 2022-04-24 14/week @ 2022-05-01 25/week @ 2022-05-08 69/week @ 2022-05-15 21/week @ 2022-05-22 33/week @ 2022-05-29 29/week @ 2022-06-05 2/week @ 2022-06-12 4/week @ 2022-06-19 1/week @ 2022-06-26 10/week @ 2022-07-03 10/week @ 2022-07-10 5/week @ 2022-07-17 9/week @ 2022-07-24 37/week @ 2022-07-31 4/week @ 2022-08-07

55 downloads per month

Apache-2.0 OR MIT

51KB
566 lines

atomic-memcpy

crates.io docs.rs license rustc build status

Byte-wise atomic memcpy.

This is an attempt to implement equivalent of C++ "P1478R1: Byte-wise atomic memcpy" in Rust.

This is expected to allow algorithms such as Seqlock and Chase-Lev deque to be implemented without UB of data races. See P1478R1 for more.

Status

  • If the alignment of the type being copied is the same as the pointer width, atomic_load is possible to produce an assembly roughly equivalent to the case of using volatile read + atomic fence on many platforms. (e.g., aarch64, riscv64. See tests/asm-test/asm directory for more).
  • If the alignment of the type being copied is smaller than the pointer width, there will be some performance degradation. However, it is implemented in such a way that it does not cause extreme performance degradation at least on x86_64. (See the implementation comments of atomic_load for more.) It is possible that there is still room for improvement, especially on non-x86_64 platforms.
  • Optimization for the case where the alignment of the type being copied is larger than the pointer width has not yet been fully investigated. It is possible that there is still room for improvement.
  • If the type being copied contains pointers it is not compatible with strict provenance because the copy does ptr-to-int transmutes.
  • If the type being copied contains uninitialized bytes (e.g., padding) it is undefined behavior because the copy goes through integers. This problem will probably not be resolved until something like AtomicMaybeUninit is supported.

Related Projects

  • portable-atomic: Portable atomic types including support for 128-bit atomics, atomic float, etc. Using byte-wise atomic memcpy to implement Seqlock, which is used in the fallback implementation.
  • atomic-maybe-uninit: Atomic operations on potentially uninitialized integers.

License

Licensed under either of Apache License, Version 2.0 or MIT license at your option.

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

Dependencies

~130KB