#[repr(C, align(16))]pub struct AtomicI128 { /* private fields */ }
Expand description
An integer type which can be safely shared between threads.
This type has the same in-memory representation as the underlying integer type,
i128
.
If the compiler and the platform support atomic loads and stores of i128
, this type is a wrapper for the standard library’s AtomicI128
. If the platform supports it but the compiler does not, atomic operations are implemented using
inline assembly. Otherwise synchronizes using global locks.
You can call AtomicI128::is_lock_free()
to check whether
atomic instructions or locks will be used.
Implementations§
source§impl AtomicI128
impl AtomicI128
sourcepub const fn new(v: i128) -> AtomicI128
pub const fn new(v: i128) -> AtomicI128
Creates a new atomic integer.
§Examples
use portable_atomic::AtomicI128;
let atomic_forty_two = AtomicI128::new(42);
sourcepub const unsafe fn from_ptr<'a>(ptr: *mut i128) -> &'a AtomicI128
pub const unsafe fn from_ptr<'a>(ptr: *mut i128) -> &'a AtomicI128
Creates a new reference to an atomic integer from a pointer.
This is const fn
on Rust 1.83+.
§Safety
ptr
must be aligned toalign_of::<AtomicI128>()
(note that on some platforms this can be bigger thanalign_of::<i128>()
).ptr
must be valid for both reads and writes for the whole lifetime'a
.- If this atomic type is lock-free, non-atomic accesses to the value
behind
ptr
must have a happens-before relationship with atomic accesses via the returned value (or vice-versa).- In other words, time periods where the value is accessed atomically may not overlap with periods where the value is accessed non-atomically.
- This requirement is trivially satisfied if
ptr
is never used non-atomically for the duration of lifetime'a
. Most use cases should be able to follow this guideline. - This requirement is also trivially satisfied if all accesses (atomic or not) are done from the same thread.
- If this atomic type is not lock-free:
- Any accesses to the value behind
ptr
must have a happens-before relationship with accesses via the returned value (or vice-versa). - Any concurrent accesses to the value behind
ptr
for the duration of lifetime'a
must be compatible with operations performed by this atomic type.
- Any accesses to the value behind
- This method must not be used to create overlapping or mixed-size atomic accesses, as these are not supported by the memory model.
sourcepub fn is_lock_free() -> bool
pub fn is_lock_free() -> bool
Returns true
if operations on values of this type are lock-free.
If the compiler or the platform doesn’t support the necessary atomic instructions, global locks for every potentially concurrent atomic operation will be used.
§Examples
use portable_atomic::AtomicI128;
let is_lock_free = AtomicI128::is_lock_free();
sourcepub const fn is_always_lock_free() -> bool
pub const fn is_always_lock_free() -> bool
Returns true
if operations on values of this type are lock-free.
If the compiler or the platform doesn’t support the necessary atomic instructions, global locks for every potentially concurrent atomic operation will be used.
Note: If the atomic operation relies on dynamic CPU feature detection, this type may be lock-free even if the function returns false.
§Examples
use portable_atomic::AtomicI128;
const IS_ALWAYS_LOCK_FREE: bool = AtomicI128::is_always_lock_free();
sourcepub const fn get_mut(&mut self) -> &mut i128
pub const fn get_mut(&mut self) -> &mut i128
Returns a mutable reference to the underlying integer.
This is safe because the mutable reference guarantees that no other threads are concurrently accessing the atomic data.
This is const fn
on Rust 1.83+.
§Examples
use portable_atomic::{AtomicI128, Ordering};
let mut some_var = AtomicI128::new(10);
assert_eq!(*some_var.get_mut(), 10);
*some_var.get_mut() = 5;
assert_eq!(some_var.load(Ordering::SeqCst), 5);
sourcepub const fn into_inner(self) -> i128
pub const fn into_inner(self) -> i128
Consumes the atomic and returns the contained value.
This is safe because passing self
by value guarantees that no other threads are
concurrently accessing the atomic data.
This is const fn
on Rust 1.56+.
§Examples
use portable_atomic::AtomicI128;
let some_var = AtomicI128::new(5);
assert_eq!(some_var.into_inner(), 5);
sourcepub fn load(&self, order: Ordering) -> i128
pub fn load(&self, order: Ordering) -> i128
Loads a value from the atomic integer.
load
takes an Ordering
argument which describes the memory ordering of this operation.
Possible values are [SeqCst
], [Acquire
] and [Relaxed
].
§Panics
Panics if order
is [Release
] or [AcqRel
].
§Examples
use portable_atomic::{AtomicI128, Ordering};
let some_var = AtomicI128::new(5);
assert_eq!(some_var.load(Ordering::Relaxed), 5);
sourcepub fn store(&self, val: i128, order: Ordering)
pub fn store(&self, val: i128, order: Ordering)
Stores a value into the atomic integer.
store
takes an Ordering
argument which describes the memory ordering of this operation.
Possible values are [SeqCst
], [Release
] and [Relaxed
].
§Panics
Panics if order
is [Acquire
] or [AcqRel
].
§Examples
use portable_atomic::{AtomicI128, Ordering};
let some_var = AtomicI128::new(5);
some_var.store(10, Ordering::Relaxed);
assert_eq!(some_var.load(Ordering::Relaxed), 10);
sourcepub fn swap(&self, val: i128, order: Ordering) -> i128
pub fn swap(&self, val: i128, order: Ordering) -> i128
Stores a value into the atomic integer, returning the previous value.
swap
takes an Ordering
argument which describes the memory ordering
of this operation. All ordering modes are possible. Note that using
[Acquire
] makes the store part of this operation [Relaxed
], and
using [Release
] makes the load part [Relaxed
].
§Examples
use portable_atomic::{AtomicI128, Ordering};
let some_var = AtomicI128::new(5);
assert_eq!(some_var.swap(10, Ordering::Relaxed), 5);
sourcepub fn compare_exchange(
&self,
current: i128,
new: i128,
success: Ordering,
failure: Ordering,
) -> Result<i128, i128>
pub fn compare_exchange( &self, current: i128, new: i128, success: Ordering, failure: Ordering, ) -> Result<i128, i128>
Stores a value into the atomic integer if the current value is the same as
the current
value.
The return value is a result indicating whether the new value was written and
containing the previous value. On success this value is guaranteed to be equal to
current
.
compare_exchange
takes two Ordering
arguments to describe the memory
ordering of this operation. success
describes the required ordering for the
read-modify-write operation that takes place if the comparison with current
succeeds.
failure
describes the required ordering for the load operation that takes place when
the comparison fails. Using [Acquire
] as success ordering makes the store part
of this operation [Relaxed
], and using [Release
] makes the successful load
[Relaxed
]. The failure ordering can only be [SeqCst
], [Acquire
] or [Relaxed
].
§Panics
Panics if failure
is [Release
], [AcqRel
].
§Examples
use portable_atomic::{AtomicI128, Ordering};
let some_var = AtomicI128::new(5);
assert_eq!(
some_var.compare_exchange(5, 10, Ordering::Acquire, Ordering::Relaxed),
Ok(5),
);
assert_eq!(some_var.load(Ordering::Relaxed), 10);
assert_eq!(
some_var.compare_exchange(6, 12, Ordering::SeqCst, Ordering::Acquire),
Err(10),
);
assert_eq!(some_var.load(Ordering::Relaxed), 10);
sourcepub fn compare_exchange_weak(
&self,
current: i128,
new: i128,
success: Ordering,
failure: Ordering,
) -> Result<i128, i128>
pub fn compare_exchange_weak( &self, current: i128, new: i128, success: Ordering, failure: Ordering, ) -> Result<i128, i128>
Stores a value into the atomic integer if the current value is the same as
the current
value.
Unlike compare_exchange
this function is allowed to spuriously fail even
when the comparison succeeds, which can result in more efficient code on some
platforms. The return value is a result indicating whether the new value was
written and containing the previous value.
compare_exchange_weak
takes two Ordering
arguments to describe the memory
ordering of this operation. success
describes the required ordering for the
read-modify-write operation that takes place if the comparison with current
succeeds.
failure
describes the required ordering for the load operation that takes place when
the comparison fails. Using [Acquire
] as success ordering makes the store part
of this operation [Relaxed
], and using [Release
] makes the successful load
[Relaxed
]. The failure ordering can only be [SeqCst
], [Acquire
] or [Relaxed
].
§Panics
Panics if failure
is [Release
], [AcqRel
].
§Examples
use portable_atomic::{AtomicI128, Ordering};
let val = AtomicI128::new(4);
let mut old = val.load(Ordering::Relaxed);
loop {
let new = old * 2;
match val.compare_exchange_weak(old, new, Ordering::SeqCst, Ordering::Relaxed) {
Ok(_) => break,
Err(x) => old = x,
}
}
sourcepub fn fetch_add(&self, val: i128, order: Ordering) -> i128
pub fn fetch_add(&self, val: i128, order: Ordering) -> i128
Adds to the current value, returning the previous value.
This operation wraps around on overflow.
fetch_add
takes an Ordering
argument which describes the memory ordering
of this operation. All ordering modes are possible. Note that using
[Acquire
] makes the store part of this operation [Relaxed
], and
using [Release
] makes the load part [Relaxed
].
§Examples
use portable_atomic::{AtomicI128, Ordering};
let foo = AtomicI128::new(0);
assert_eq!(foo.fetch_add(10, Ordering::SeqCst), 0);
assert_eq!(foo.load(Ordering::SeqCst), 10);
sourcepub fn add(&self, val: i128, order: Ordering)
pub fn add(&self, val: i128, order: Ordering)
Adds to the current value.
This operation wraps around on overflow.
Unlike fetch_add
, this does not return the previous value.
add
takes an Ordering
argument which describes the memory ordering
of this operation. All ordering modes are possible. Note that using
[Acquire
] makes the store part of this operation [Relaxed
], and
using [Release
] makes the load part [Relaxed
].
This function may generate more efficient code than fetch_add
on some platforms.
- MSP430:
add
instead of disabling interrupts ({8,16}-bit atomics)
§Examples
use portable_atomic::{AtomicI128, Ordering};
let foo = AtomicI128::new(0);
foo.add(10, Ordering::SeqCst);
assert_eq!(foo.load(Ordering::SeqCst), 10);
sourcepub fn fetch_sub(&self, val: i128, order: Ordering) -> i128
pub fn fetch_sub(&self, val: i128, order: Ordering) -> i128
Subtracts from the current value, returning the previous value.
This operation wraps around on overflow.
fetch_sub
takes an Ordering
argument which describes the memory ordering
of this operation. All ordering modes are possible. Note that using
[Acquire
] makes the store part of this operation [Relaxed
], and
using [Release
] makes the load part [Relaxed
].
§Examples
use portable_atomic::{AtomicI128, Ordering};
let foo = AtomicI128::new(20);
assert_eq!(foo.fetch_sub(10, Ordering::SeqCst), 20);
assert_eq!(foo.load(Ordering::SeqCst), 10);
sourcepub fn sub(&self, val: i128, order: Ordering)
pub fn sub(&self, val: i128, order: Ordering)
Subtracts from the current value.
This operation wraps around on overflow.
Unlike fetch_sub
, this does not return the previous value.
sub
takes an Ordering
argument which describes the memory ordering
of this operation. All ordering modes are possible. Note that using
[Acquire
] makes the store part of this operation [Relaxed
], and
using [Release
] makes the load part [Relaxed
].
This function may generate more efficient code than fetch_sub
on some platforms.
- MSP430:
sub
instead of disabling interrupts ({8,16}-bit atomics)
§Examples
use portable_atomic::{AtomicI128, Ordering};
let foo = AtomicI128::new(20);
foo.sub(10, Ordering::SeqCst);
assert_eq!(foo.load(Ordering::SeqCst), 10);
sourcepub fn fetch_and(&self, val: i128, order: Ordering) -> i128
pub fn fetch_and(&self, val: i128, order: Ordering) -> i128
Bitwise “and” with the current value.
Performs a bitwise “and” operation on the current value and the argument val
, and
sets the new value to the result.
Returns the previous value.
fetch_and
takes an Ordering
argument which describes the memory ordering
of this operation. All ordering modes are possible. Note that using
[Acquire
] makes the store part of this operation [Relaxed
], and
using [Release
] makes the load part [Relaxed
].
§Examples
use portable_atomic::{AtomicI128, Ordering};
let foo = AtomicI128::new(0b101101);
assert_eq!(foo.fetch_and(0b110011, Ordering::SeqCst), 0b101101);
assert_eq!(foo.load(Ordering::SeqCst), 0b100001);
sourcepub fn and(&self, val: i128, order: Ordering)
pub fn and(&self, val: i128, order: Ordering)
Bitwise “and” with the current value.
Performs a bitwise “and” operation on the current value and the argument val
, and
sets the new value to the result.
Unlike fetch_and
, this does not return the previous value.
and
takes an Ordering
argument which describes the memory ordering
of this operation. All ordering modes are possible. Note that using
[Acquire
] makes the store part of this operation [Relaxed
], and
using [Release
] makes the load part [Relaxed
].
This function may generate more efficient code than fetch_and
on some platforms.
- x86/x86_64:
lock and
instead ofcmpxchg
loop ({8,16,32}-bit atomics on x86, but additionally 64-bit atomics on x86_64) - MSP430:
and
instead of disabling interrupts ({8,16}-bit atomics)
Note: On x86/x86_64, the use of either function should not usually affect the generated code, because LLVM can properly optimize the case where the result is unused.
§Examples
use portable_atomic::{AtomicI128, Ordering};
let foo = AtomicI128::new(0b101101);
assert_eq!(foo.fetch_and(0b110011, Ordering::SeqCst), 0b101101);
assert_eq!(foo.load(Ordering::SeqCst), 0b100001);
sourcepub fn fetch_nand(&self, val: i128, order: Ordering) -> i128
pub fn fetch_nand(&self, val: i128, order: Ordering) -> i128
Bitwise “nand” with the current value.
Performs a bitwise “nand” operation on the current value and the argument val
, and
sets the new value to the result.
Returns the previous value.
fetch_nand
takes an Ordering
argument which describes the memory ordering
of this operation. All ordering modes are possible. Note that using
[Acquire
] makes the store part of this operation [Relaxed
], and
using [Release
] makes the load part [Relaxed
].
§Examples
use portable_atomic::{AtomicI128, Ordering};
let foo = AtomicI128::new(0x13);
assert_eq!(foo.fetch_nand(0x31, Ordering::SeqCst), 0x13);
assert_eq!(foo.load(Ordering::SeqCst), !(0x13 & 0x31));
sourcepub fn fetch_or(&self, val: i128, order: Ordering) -> i128
pub fn fetch_or(&self, val: i128, order: Ordering) -> i128
Bitwise “or” with the current value.
Performs a bitwise “or” operation on the current value and the argument val
, and
sets the new value to the result.
Returns the previous value.
fetch_or
takes an Ordering
argument which describes the memory ordering
of this operation. All ordering modes are possible. Note that using
[Acquire
] makes the store part of this operation [Relaxed
], and
using [Release
] makes the load part [Relaxed
].
§Examples
use portable_atomic::{AtomicI128, Ordering};
let foo = AtomicI128::new(0b101101);
assert_eq!(foo.fetch_or(0b110011, Ordering::SeqCst), 0b101101);
assert_eq!(foo.load(Ordering::SeqCst), 0b111111);
sourcepub fn or(&self, val: i128, order: Ordering)
pub fn or(&self, val: i128, order: Ordering)
Bitwise “or” with the current value.
Performs a bitwise “or” operation on the current value and the argument val
, and
sets the new value to the result.
Unlike fetch_or
, this does not return the previous value.
or
takes an Ordering
argument which describes the memory ordering
of this operation. All ordering modes are possible. Note that using
[Acquire
] makes the store part of this operation [Relaxed
], and
using [Release
] makes the load part [Relaxed
].
This function may generate more efficient code than fetch_or
on some platforms.
- x86/x86_64:
lock or
instead ofcmpxchg
loop ({8,16,32}-bit atomics on x86, but additionally 64-bit atomics on x86_64) - MSP430:
or
instead of disabling interrupts ({8,16}-bit atomics)
Note: On x86/x86_64, the use of either function should not usually affect the generated code, because LLVM can properly optimize the case where the result is unused.
§Examples
use portable_atomic::{AtomicI128, Ordering};
let foo = AtomicI128::new(0b101101);
assert_eq!(foo.fetch_or(0b110011, Ordering::SeqCst), 0b101101);
assert_eq!(foo.load(Ordering::SeqCst), 0b111111);
sourcepub fn fetch_xor(&self, val: i128, order: Ordering) -> i128
pub fn fetch_xor(&self, val: i128, order: Ordering) -> i128
Bitwise “xor” with the current value.
Performs a bitwise “xor” operation on the current value and the argument val
, and
sets the new value to the result.
Returns the previous value.
fetch_xor
takes an Ordering
argument which describes the memory ordering
of this operation. All ordering modes are possible. Note that using
[Acquire
] makes the store part of this operation [Relaxed
], and
using [Release
] makes the load part [Relaxed
].
§Examples
use portable_atomic::{AtomicI128, Ordering};
let foo = AtomicI128::new(0b101101);
assert_eq!(foo.fetch_xor(0b110011, Ordering::SeqCst), 0b101101);
assert_eq!(foo.load(Ordering::SeqCst), 0b011110);
sourcepub fn xor(&self, val: i128, order: Ordering)
pub fn xor(&self, val: i128, order: Ordering)
Bitwise “xor” with the current value.
Performs a bitwise “xor” operation on the current value and the argument val
, and
sets the new value to the result.
Unlike fetch_xor
, this does not return the previous value.
xor
takes an Ordering
argument which describes the memory ordering
of this operation. All ordering modes are possible. Note that using
[Acquire
] makes the store part of this operation [Relaxed
], and
using [Release
] makes the load part [Relaxed
].
This function may generate more efficient code than fetch_xor
on some platforms.
- x86/x86_64:
lock xor
instead ofcmpxchg
loop ({8,16,32}-bit atomics on x86, but additionally 64-bit atomics on x86_64) - MSP430:
xor
instead of disabling interrupts ({8,16}-bit atomics)
Note: On x86/x86_64, the use of either function should not usually affect the generated code, because LLVM can properly optimize the case where the result is unused.
§Examples
use portable_atomic::{AtomicI128, Ordering};
let foo = AtomicI128::new(0b101101);
foo.xor(0b110011, Ordering::SeqCst);
assert_eq!(foo.load(Ordering::SeqCst), 0b011110);
sourcepub fn fetch_update<F>(
&self,
set_order: Ordering,
fetch_order: Ordering,
f: F,
) -> Result<i128, i128>
pub fn fetch_update<F>( &self, set_order: Ordering, fetch_order: Ordering, f: F, ) -> Result<i128, i128>
Fetches the value, and applies a function to it that returns an optional
new value. Returns a Result
of Ok(previous_value)
if the function returned Some(_)
, else
Err(previous_value)
.
Note: This may call the function multiple times if the value has been changed from other threads in
the meantime, as long as the function returns Some(_)
, but the function will have been applied
only once to the stored value.
fetch_update
takes two Ordering
arguments to describe the memory ordering of this operation.
The first describes the required ordering for when the operation finally succeeds while the second
describes the required ordering for loads. These correspond to the success and failure orderings of
compare_exchange
respectively.
Using [Acquire
] as success ordering makes the store part
of this operation [Relaxed
], and using [Release
] makes the final successful load
[Relaxed
]. The (failed) load ordering can only be [SeqCst
], [Acquire
] or [Relaxed
].
§Panics
Panics if fetch_order
is [Release
], [AcqRel
].
§Considerations
This method is not magic; it is not provided by the hardware.
It is implemented in terms of compare_exchange_weak
,
and suffers from the same drawbacks.
In particular, this method will not circumvent the ABA Problem.
§Examples
use portable_atomic::{AtomicI128, Ordering};
let x = AtomicI128::new(7);
assert_eq!(x.fetch_update(Ordering::SeqCst, Ordering::SeqCst, |_| None), Err(7));
assert_eq!(x.fetch_update(Ordering::SeqCst, Ordering::SeqCst, |x| Some(x + 1)), Ok(7));
assert_eq!(x.fetch_update(Ordering::SeqCst, Ordering::SeqCst, |x| Some(x + 1)), Ok(8));
assert_eq!(x.load(Ordering::SeqCst), 9);
sourcepub fn fetch_max(&self, val: i128, order: Ordering) -> i128
pub fn fetch_max(&self, val: i128, order: Ordering) -> i128
Maximum with the current value.
Finds the maximum of the current value and the argument val
, and
sets the new value to the result.
Returns the previous value.
fetch_max
takes an Ordering
argument which describes the memory ordering
of this operation. All ordering modes are possible. Note that using
[Acquire
] makes the store part of this operation [Relaxed
], and
using [Release
] makes the load part [Relaxed
].
§Examples
use portable_atomic::{AtomicI128, Ordering};
let foo = AtomicI128::new(23);
assert_eq!(foo.fetch_max(42, Ordering::SeqCst), 23);
assert_eq!(foo.load(Ordering::SeqCst), 42);
If you want to obtain the maximum value in one step, you can use the following:
use portable_atomic::{AtomicI128, Ordering};
let foo = AtomicI128::new(23);
let bar = 42;
let max_foo = foo.fetch_max(bar, Ordering::SeqCst).max(bar);
assert!(max_foo == 42);
sourcepub fn fetch_min(&self, val: i128, order: Ordering) -> i128
pub fn fetch_min(&self, val: i128, order: Ordering) -> i128
Minimum with the current value.
Finds the minimum of the current value and the argument val
, and
sets the new value to the result.
Returns the previous value.
fetch_min
takes an Ordering
argument which describes the memory ordering
of this operation. All ordering modes are possible. Note that using
[Acquire
] makes the store part of this operation [Relaxed
], and
using [Release
] makes the load part [Relaxed
].
§Examples
use portable_atomic::{AtomicI128, Ordering};
let foo = AtomicI128::new(23);
assert_eq!(foo.fetch_min(42, Ordering::Relaxed), 23);
assert_eq!(foo.load(Ordering::Relaxed), 23);
assert_eq!(foo.fetch_min(22, Ordering::Relaxed), 23);
assert_eq!(foo.load(Ordering::Relaxed), 22);
If you want to obtain the minimum value in one step, you can use the following:
use portable_atomic::{AtomicI128, Ordering};
let foo = AtomicI128::new(23);
let bar = 12;
let min_foo = foo.fetch_min(bar, Ordering::SeqCst).min(bar);
assert_eq!(min_foo, 12);
sourcepub fn bit_set(&self, bit: u32, order: Ordering) -> bool
pub fn bit_set(&self, bit: u32, order: Ordering) -> bool
Sets the bit at the specified bit-position to 1.
Returns true
if the specified bit was previously set to 1.
bit_set
takes an Ordering
argument which describes the memory ordering
of this operation. All ordering modes are possible. Note that using
[Acquire
] makes the store part of this operation [Relaxed
], and
using [Release
] makes the load part [Relaxed
].
This corresponds to x86’s lock bts
, and the implementation calls them on x86/x86_64.
§Examples
use portable_atomic::{AtomicI128, Ordering};
let foo = AtomicI128::new(0b0000);
assert!(!foo.bit_set(0, Ordering::Relaxed));
assert_eq!(foo.load(Ordering::Relaxed), 0b0001);
assert!(foo.bit_set(0, Ordering::Relaxed));
assert_eq!(foo.load(Ordering::Relaxed), 0b0001);
sourcepub fn bit_clear(&self, bit: u32, order: Ordering) -> bool
pub fn bit_clear(&self, bit: u32, order: Ordering) -> bool
Clears the bit at the specified bit-position to 1.
Returns true
if the specified bit was previously set to 1.
bit_clear
takes an Ordering
argument which describes the memory ordering
of this operation. All ordering modes are possible. Note that using
[Acquire
] makes the store part of this operation [Relaxed
], and
using [Release
] makes the load part [Relaxed
].
This corresponds to x86’s lock btr
, and the implementation calls them on x86/x86_64.
§Examples
use portable_atomic::{AtomicI128, Ordering};
let foo = AtomicI128::new(0b0001);
assert!(foo.bit_clear(0, Ordering::Relaxed));
assert_eq!(foo.load(Ordering::Relaxed), 0b0000);
sourcepub fn bit_toggle(&self, bit: u32, order: Ordering) -> bool
pub fn bit_toggle(&self, bit: u32, order: Ordering) -> bool
Toggles the bit at the specified bit-position.
Returns true
if the specified bit was previously set to 1.
bit_toggle
takes an Ordering
argument which describes the memory ordering
of this operation. All ordering modes are possible. Note that using
[Acquire
] makes the store part of this operation [Relaxed
], and
using [Release
] makes the load part [Relaxed
].
This corresponds to x86’s lock btc
, and the implementation calls them on x86/x86_64.
§Examples
use portable_atomic::{AtomicI128, Ordering};
let foo = AtomicI128::new(0b0000);
assert!(!foo.bit_toggle(0, Ordering::Relaxed));
assert_eq!(foo.load(Ordering::Relaxed), 0b0001);
assert!(foo.bit_toggle(0, Ordering::Relaxed));
assert_eq!(foo.load(Ordering::Relaxed), 0b0000);
sourcepub fn fetch_not(&self, order: Ordering) -> i128
pub fn fetch_not(&self, order: Ordering) -> i128
Logical negates the current value, and sets the new value to the result.
Returns the previous value.
fetch_not
takes an Ordering
argument which describes the memory ordering
of this operation. All ordering modes are possible. Note that using
[Acquire
] makes the store part of this operation [Relaxed
], and
using [Release
] makes the load part [Relaxed
].
§Examples
use portable_atomic::{AtomicI128, Ordering};
let foo = AtomicI128::new(0);
assert_eq!(foo.fetch_not(Ordering::Relaxed), 0);
assert_eq!(foo.load(Ordering::Relaxed), !0);
sourcepub fn not(&self, order: Ordering)
pub fn not(&self, order: Ordering)
Logical negates the current value, and sets the new value to the result.
Unlike fetch_not
, this does not return the previous value.
not
takes an Ordering
argument which describes the memory ordering
of this operation. All ordering modes are possible. Note that using
[Acquire
] makes the store part of this operation [Relaxed
], and
using [Release
] makes the load part [Relaxed
].
This function may generate more efficient code than fetch_not
on some platforms.
- x86/x86_64:
lock not
instead ofcmpxchg
loop ({8,16,32}-bit atomics on x86, but additionally 64-bit atomics on x86_64) - MSP430:
inv
instead of disabling interrupts ({8,16}-bit atomics)
§Examples
use portable_atomic::{AtomicI128, Ordering};
let foo = AtomicI128::new(0);
foo.not(Ordering::Relaxed);
assert_eq!(foo.load(Ordering::Relaxed), !0);
sourcepub fn fetch_neg(&self, order: Ordering) -> i128
pub fn fetch_neg(&self, order: Ordering) -> i128
Negates the current value, and sets the new value to the result.
Returns the previous value.
fetch_neg
takes an Ordering
argument which describes the memory ordering
of this operation. All ordering modes are possible. Note that using
[Acquire
] makes the store part of this operation [Relaxed
], and
using [Release
] makes the load part [Relaxed
].
§Examples
use portable_atomic::{AtomicI128, Ordering};
let foo = AtomicI128::new(5);
assert_eq!(foo.fetch_neg(Ordering::Relaxed), 5);
assert_eq!(foo.load(Ordering::Relaxed), 5_i128.wrapping_neg());
assert_eq!(foo.fetch_neg(Ordering::Relaxed), 5_i128.wrapping_neg());
assert_eq!(foo.load(Ordering::Relaxed), 5);
sourcepub fn neg(&self, order: Ordering)
pub fn neg(&self, order: Ordering)
Negates the current value, and sets the new value to the result.
Unlike fetch_neg
, this does not return the previous value.
neg
takes an Ordering
argument which describes the memory ordering
of this operation. All ordering modes are possible. Note that using
[Acquire
] makes the store part of this operation [Relaxed
], and
using [Release
] makes the load part [Relaxed
].
This function may generate more efficient code than fetch_neg
on some platforms.
- x86/x86_64:
lock neg
instead ofcmpxchg
loop ({8,16,32}-bit atomics on x86, but additionally 64-bit atomics on x86_64)
§Examples
use portable_atomic::{AtomicI128, Ordering};
let foo = AtomicI128::new(5);
foo.neg(Ordering::Relaxed);
assert_eq!(foo.load(Ordering::Relaxed), 5_i128.wrapping_neg());
foo.neg(Ordering::Relaxed);
assert_eq!(foo.load(Ordering::Relaxed), 5);
sourcepub const fn as_ptr(&self) -> *mut i128
pub const fn as_ptr(&self) -> *mut i128
Returns a mutable pointer to the underlying integer.
Returning an *mut
pointer from a shared reference to this atomic is
safe because the atomic types work with interior mutability. Any use of
the returned raw pointer requires an unsafe
block and has to uphold
the safety requirements. If there is concurrent access, note the following
additional safety requirements:
- If this atomic type is lock-free, any concurrent operations on it must be atomic.
- Otherwise, any concurrent operations on it must be compatible with operations performed by this atomic type.
This is const fn
on Rust 1.58+.