GitXplorerGitXplorer
t

atomic-memcpy

public
30 stars
0 forks
1 issues

Commits

List of commits on branch main.
Unverified
35a4d5b6ebddaab03c120164a4167214c866a534

ci: Disable buggy dependabot grouped update

ttaiki-e committed 2 days ago
Unverified
5e4a063508c78ee725d07af49652d449c739af24

tools: Format shell scripts with indent_size = 2 to match scripts in CI config

ttaiki-e committed 2 days ago
Unverified
e0d727e6c4d7f649ae07675253d598a507a98530

Update rust-lang/rust links

ttaiki-e committed 3 days ago
Unverified
a06f59e41ff690f76e8d40b6cd1773731e0499e4

Add MSRV reason comment

ttaiki-e committed 4 days ago
Unverified
1946acab7f2a02eab9fdb7ca46470cfaeb2a0481

Apply clippy::unused_trait_names lint

ttaiki-e committed 5 days ago
Unverified
d9a0fbddd71bd43c36c7bc9573e4d0f224bd9e50

ci: Update reusable workflows

ttaiki-e committed 6 days ago

README

The README file for this repository.

atomic-memcpy

crates.io docs.rs license msrv github actions

Byte-wise atomic memcpy.

This is an attempt to implement equivalent of C++ "P1478: 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 P1478 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.