Like it or not, atomic-polyfill and portable-atomic both exist as crates solving the same problem of "providing atomic primitives to targets that don't have them" in different ways. The major difference between the two crates is that:

1. atomic-polyfill depends on critical-section, and expects another crate to define extern functions acquire and release. The critical-sectioncrate uses acquire and release to implement critical sections. If acquire and release aren't defined by an external crate, a link error will occur. In other words, the critical section implementation can be swapped out with another.
2. portable-atomic implements critical sections for all targets within the portable-atomic crate, and does not defer to an external crate.

According to reverse dependencies on crates.io, these two crates don't have any shared reverse dependencies, and some of these reverse deps have 10 million+ downloads. This means it's plausible to have both crates in the same dependency graph. And this means it's also plausible that these two crates in the same dependency graph implement critical sections in different ways.

Is this a soundness problem in practice? I can't visualize one, since types from this crate won't share memory locations with types from atomic-polyfill. But it's enough to get me thinking and open an issue. If it is a soundness issue as opposed to simply "two crates doing the same thing in different ways are in the same dependency graph", is it possible to fail the build if both crates get pulled in, or automatically have portable-atomic be a shim for atomic-polyfill (or vice-versa)?

As we have already been doing for pre-v6 ARM, avoid unneeded branch and mask.

https://github.com/taiki-e/portable-atomic/blob/d4b27473dd7d62a6d5a453e78b1629a1ce24d086/src/imp/interrupt/armv4t.rs#L31-L40

Since pre-v6[^v6] ARM has no Data Memory Barrier and cannot implement atomic in a way compatible with v6 and later multicore CPUs without OS helpers, LLVM generates libcalls for atomic operations that require synchronization, such as Acquire/Release and SeqCst.

Currently, (when portable_atomic_unsafe_assume_single_core cfg is used) we consider this as "atomic load/store are not available on pre-v6 ARM" and always disable interrupts. However, relaxed load+compiler fence can do this more efficiently since we know it is single-core.

https://github.com/taiki-e/portable-atomic/blob/e6e1500f440e6a79d87f4471924c5e6613594b51/src/imp/interrupt/mod.rs#L34-L35

https://github.com/taiki-e/portable-atomic/blob/e6e1500f440e6a79d87f4471924c5e6613594b51/src/imp/interrupt/mod.rs#L23-L29

FYI @Lokathor

[^v6]: ARMv6 except for ARMv6-M also does not have the DMB instruction, but there is a special instruction equivalent to DMB.

Closes #26

This currently disables only IRQs. This is explained in the document on safety requirements:

• On pre-v6 ARM, this currently disables only IRQs. Enabling this cfg in an environment where FIQs must also be disabled is also considered unsound.

I have a few questions:

• ~~Should we also disable FIQs? The emulation of atomic operation on Linux seemed to disable only IRQs, but they may have disabled FIQs globally.~~ EDIT: see https://github.com/taiki-e/portable-atomic/pull/28#issuecomment-1214146912
• Is there a way to test this target on CI?

x86_64 part of #10

The following are the results of a simple microbenchmark:

bench_portable_atomic_arch/u128_load
                        time:   [1.4598 ns 1.4671 ns 1.4753 ns]
                        change: [-81.510% -81.210% -80.950%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 7 outliers among 100 measurements (7.00%)
  1 (1.00%) low mild
  4 (4.00%) high mild
  2 (2.00%) high severe
bench_portable_atomic_arch/u128_store
                        time:   [1.3852 ns 1.3937 ns 1.4024 ns]
                        change: [-82.318% -81.989% -81.621%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 10 outliers among 100 measurements (10.00%)
  3 (3.00%) low mild
  5 (5.00%) high mild
  2 (2.00%) high severe
bench_portable_atomic_arch/u128_concurrent_load
                        time:   [56.422 us 56.767 us 57.204 us]
                        change: [-70.807% -70.143% -69.443%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 9 outliers among 100 measurements (9.00%)
  3 (3.00%) high mild
  6 (6.00%) high severe
bench_portable_atomic_arch/u128_concurrent_load_store
                        time:   [136.53 us 139.96 us 145.39 us]
                        change: [-82.570% -81.879% -80.820%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 15 outliers among 100 measurements (15.00%)
  4 (4.00%) high mild
  11 (11.00%) high severe
bench_portable_atomic_arch/u128_concurrent_store
                        time:   [146.03 us 147.67 us 149.98 us]
                        change: [-90.486% -90.124% -89.483%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 9 outliers among 100 measurements (9.00%)
  1 (1.00%) high mild
  8 (8.00%) high severe
bench_portable_atomic_arch/u128_concurrent_store_swap
                        time:   [765.11 us 766.69 us 768.29 us]
                        change: [-51.204% -50.967% -50.745%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 7 outliers among 100 measurements (7.00%)
  4 (4.00%) low mild
  2 (2.00%) high mild
  1 (1.00%) high severe

Closes #10

This enables outline-atomics feature by default and provides portable_atomic_no_outline_atomics cfg to disable it.

(outline-atomics enables several optimizations on x86_64 and aarch64. See this list for details.)

It has previously been pointed out that due to the nature of the cargo feature, controlling this based on the cargo feature does not work well. Since this release, outline-atomics feature has been no-op, and outline-atomics is enabled by default.

Note: outline-atomics in portable-atomics is currently for 128-bit atomics. outline-atomics for atomics with other sizes is controlled by LLVM's outline-atomics target feature.

Closes #25

This adds Atomic{I,U}*::{add,sub,and,or,xor} and AtomicBool::{and,or,xor} methods.

They are equivalent to the corresponding fetch_* methods, but do not return the previous value. They are intended for optimization on platforms that implement atomics using inline assembly, such as the MSP430.

Currently, optimizations by these methods (add,sub,and,or,xor) are only guaranteed for MSP430; on x86, LLVM can optimize in most cases, so cases, where this would improve things, should be rare.

See https://github.com/pftbest/msp430-atomic/issues/7 for the context. cc @cr1901 @YuhanLiin

This pull requests resolves #37 by adding Arc and Weak types to the portable-atomic-util crate that use portable_atomic::AtomicUsize in their operation. The goal is to allow for portable using of Arc on platforms that may have allocation but not atomics. Arduino AVR comes to mind for this.

These new types are based off of the ones in libstd, but I explicitly avoid using unstable features. I do not implement unstable functions, like new_uninit. I also avoided certain functions like new_cyclic and take_mut because I didn't get around to it.

Processors that enumerate support for Intel® AVX (by setting the feature flag CPUID.01H:ECX.AVX[bit 28]) guarantee that the 16-byte memory operations performed by the following instructions will always be carried out atomically:

• MOVAPD, MOVAPS, and MOVDQA.
• VMOVAPD, VMOVAPS, and VMOVDQA when encoded with VEX.128.
• VMOVAPD, VMOVAPS, VMOVDQA32, and VMOVDQA64 when encoded with EVEX.128 and k0 (masking disabled).

(Note that these instructions require the linear addresses of their memory operands to be 16-byte aligned.)

AtomicU128::{load, store} can take advantage of this instead of using the more expensive cmpxchg instruction. See this GCC issue/patch for details: https://gcc.gnu.org/bugzilla//show_bug.cgi?id=104688.

Part of #48

• Add AtomicI*::{fetch_neg,neg} and AtomicF*::fetch_neg methods.

  AtomicI*::neg are equivalent to the corresponding fetch_* methods, but do not return the previous value. They are intended for optimization on platforms that have atomic instructions for the corresponding operation, such as x86's lock neg.

  Currently, optimizations by these methods (neg) are only guaranteed for x86.

• Add Atomic{I,U}*::{fetch_not,not} methods.

  Atomic{I,U}*::not are equivalent to the corresponding fetch_* methods, but do not return the previous value. They are intended for optimization on platforms that have atomic instructions for the corresponding operation, such as x86's lock not, MSP430's inv.

  Currently, optimizations by these methods (not) are only guaranteed for x86 and MSP430.

  (Note: AtomicBool already has fetch_not and not methods.)

If it is specified multiple times, the last value will be preferred.

// build.rs
use std::env;
fn main() {
    println!("cargo:rerun-if-env-changed=PREFER_FIRST");
    if env::var_os("PREFER_FIRST").is_some() {
        if is_allowed_feature1("core_intrinsics") {
            println!("cargo:rustc-cfg=core_intrinsics");
        }
        if is_allowed_feature1("asm_const") {
            println!("cargo:rustc-cfg=asm_const");
        }
    } else {
        if is_allowed_feature2("core_intrinsics") {
            println!("cargo:rustc-cfg=core_intrinsics");
        }
        if is_allowed_feature2("asm_const") {
            println!("cargo:rustc-cfg=asm_const");
        }
    }
}
fn is_allowed_feature1(name: &str) -> bool {
    if let Some(rustflags) = env::var_os("CARGO_ENCODED_RUSTFLAGS") {
        for mut flag in rustflags.to_string_lossy().split('\x1f') {
            flag = flag.strip_prefix("-Z").unwrap_or(flag);
            if let Some(flag) = flag.strip_prefix("allow-features=") {
                return flag.split(',').any(|allowed| allowed == name);
            }
        }
    }
    // allowed by default
    true
}
fn is_allowed_feature2(name: &str) -> bool {
    // allowed by default
    let mut allowed = true;
    if let Some(rustflags) = env::var_os("CARGO_ENCODED_RUSTFLAGS") {
        for mut flag in rustflags.to_string_lossy().split('\x1f') {
            flag = flag.strip_prefix("-Z").unwrap_or(flag);
            if let Some(flag) = flag.strip_prefix("allow-features=") {
                // If it is specified multiple times, the previous value will be overwritten.
                allowed = flag.split(',').any(|allowed| allowed == name);
            }
        }
    }
    allowed
}

// lib.rs
#![cfg_attr(core_intrinsics, feature(core_intrinsics))]
#![cfg_attr(asm_const, feature(asm_const))]

$ PREFER_FIRST=1 RUSTFLAGS='-Z allow-features=asm_const -Z allow-features=core_intrinsics' cargo build
error[E0725]: the feature `asm_const` is not in the list of allowed features
 --> src/lib.rs:2:32
  |
2 | #![cfg_attr(asm_const, feature(asm_const))]
  |                                ^^^^^^^^^
$ RUSTFLAGS='-Z allow-features=asm_const -Z allow-features=core_intrinsics' cargo build
    Finished dev [unoptimized + debuginfo] target(s) in 0.12s

(The first commit is from #52.)

Replaces #21.

As said in https://github.com/taiki-e/portable-atomic/pull/21#issuecomment-1345486320, adopt the approach using cfg.

cc https://github.com/taiki-e/portable-atomic/issues/10

The slowest job in our CI (build (nightly)) takes over an hour. This is a really annoying situation, so let's investigate if we can shorten the time.

I want to depreecate atomic-polyfill in favor of portable-atomic. This is the only thing left that portable-atomic can't do, so here it goes.

PR is still missing updating docs. I'll do it if you confirm you're onboard with the idea of supporting using critical-section.

The following are the atomic operations supported by the x86 lock prefix.

ADD, ADC, AND, BTC, BTR, BTS, CMPXCHG, CMPXCH8B, CMPXCHG16B, DEC, INC, NEG, NOT, OR, SBB, SUB, XOR, XADD, and XCHG.

We currently do not provide corresponding operations for BTC, BTR, BTS, NEG, and NOT. (To be exact, BTC, BTR, and BTS are available via other operations on Rust 1.65+, but it would probably make sense to have dedicated methods like Zig)

I don't think NEG and NOT return the previous value, but can be provided in a way like #47.

• [ ] BTS (fetch_bit_set?)
• [ ] BTR (fetch_bit_reset or fetch_bit_clear?)
• [ ] BTC (fetch_bit_toggle?)
• [x] NEG (fetch_neg, neg); done in https://github.com/taiki-e/portable-atomic/pull/54
• [x] NOT (fetch_not, not); done in https://github.com/taiki-e/portable-atomic/pull/54

I would like to create the initial release of portable-atomic-util as #41 merged.

This tracks the TODOs required for the release.

Open questions

• [ ] Should the version be the same version as the main portable-atomic crate?
  • I feel that it should not be; when portable-atomic is released as 1.0, I would not expect portable-atomic-util to be stable enough to be 1.0.

TODOs

• [ ] Update release workflow for portable-atomic-util