#[repr(C, align(1))]pub struct AtomicBool { /* private fields */ }
Expand description
A boolean type which can be safely shared between threads.
This type has the same in-memory representation as a bool
.
If the compiler and the platform support atomic loads and stores of u8
,
this type is a wrapper for the standard library’s
AtomicBool
. If the platform supports it
but the compiler does not, atomic operations are implemented using inline
assembly.
Implementations§
source§impl AtomicBool
impl AtomicBool
sourcepub const fn new(v: bool) -> Self
pub const fn new(v: bool) -> Self
Creates a new AtomicBool
.
§Examples
use portable_atomic::AtomicBool;
let atomic_true = AtomicBool::new(true);
let atomic_false = AtomicBool::new(false);
sourcepub unsafe fn from_ptr<'a>(ptr: *mut bool) -> &'a Self
pub unsafe fn from_ptr<'a>(ptr: *mut bool) -> &'a Self
Creates a new AtomicBool
from a pointer.
§Safety
ptr
must be aligned toalign_of::<AtomicBool>()
(note that on some platforms this can be bigger thanalign_of::<bool>()
).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::AtomicBool;
let is_lock_free = AtomicBool::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::AtomicBool;
const IS_ALWAYS_LOCK_FREE: bool = AtomicBool::is_always_lock_free();
sourcepub fn get_mut(&mut self) -> &mut bool
pub fn get_mut(&mut self) -> &mut bool
Returns a mutable reference to the underlying bool
.
This is safe because the mutable reference guarantees that no other threads are concurrently accessing the atomic data.
§Examples
use portable_atomic::{AtomicBool, Ordering};
let mut some_bool = AtomicBool::new(true);
assert_eq!(*some_bool.get_mut(), true);
*some_bool.get_mut() = false;
assert_eq!(some_bool.load(Ordering::SeqCst), false);
sourcepub const fn into_inner(self) -> bool
pub const fn into_inner(self) -> bool
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::AtomicBool;
let some_bool = AtomicBool::new(true);
assert_eq!(some_bool.into_inner(), true);
sourcepub fn load(&self, order: Ordering) -> bool
pub fn load(&self, order: Ordering) -> bool
Loads a value from the bool.
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::{AtomicBool, Ordering};
let some_bool = AtomicBool::new(true);
assert_eq!(some_bool.load(Ordering::Relaxed), true);
sourcepub fn store(&self, val: bool, order: Ordering)
pub fn store(&self, val: bool, order: Ordering)
Stores a value into the bool.
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::{AtomicBool, Ordering};
let some_bool = AtomicBool::new(true);
some_bool.store(false, Ordering::Relaxed);
assert_eq!(some_bool.load(Ordering::Relaxed), false);
sourcepub fn swap(&self, val: bool, order: Ordering) -> bool
pub fn swap(&self, val: bool, order: Ordering) -> bool
Stores a value into the bool, 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::{AtomicBool, Ordering};
let some_bool = AtomicBool::new(true);
assert_eq!(some_bool.swap(false, Ordering::Relaxed), true);
assert_eq!(some_bool.load(Ordering::Relaxed), false);
sourcepub fn compare_exchange(
&self,
current: bool,
new: bool,
success: Ordering,
failure: Ordering,
) -> Result<bool, bool>
pub fn compare_exchange( &self, current: bool, new: bool, success: Ordering, failure: Ordering, ) -> Result<bool, bool>
Stores a value into the bool
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::{AtomicBool, Ordering};
let some_bool = AtomicBool::new(true);
assert_eq!(
some_bool.compare_exchange(true, false, Ordering::Acquire, Ordering::Relaxed),
Ok(true)
);
assert_eq!(some_bool.load(Ordering::Relaxed), false);
assert_eq!(
some_bool.compare_exchange(true, true, Ordering::SeqCst, Ordering::Acquire),
Err(false)
);
assert_eq!(some_bool.load(Ordering::Relaxed), false);
sourcepub fn compare_exchange_weak(
&self,
current: bool,
new: bool,
success: Ordering,
failure: Ordering,
) -> Result<bool, bool>
pub fn compare_exchange_weak( &self, current: bool, new: bool, success: Ordering, failure: Ordering, ) -> Result<bool, bool>
Stores a value into the bool
if the current value is the same as the current
value.
Unlike AtomicBool::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::{AtomicBool, Ordering};
let val = AtomicBool::new(false);
let new = true;
let mut old = val.load(Ordering::Relaxed);
loop {
match val.compare_exchange_weak(old, new, Ordering::SeqCst, Ordering::Relaxed) {
Ok(_) => break,
Err(x) => old = x,
}
}
sourcepub fn fetch_and(&self, val: bool, order: Ordering) -> bool
pub fn fetch_and(&self, val: bool, order: Ordering) -> bool
Logical “and” with a boolean value.
Performs a logical “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::{AtomicBool, Ordering};
let foo = AtomicBool::new(true);
assert_eq!(foo.fetch_and(false, Ordering::SeqCst), true);
assert_eq!(foo.load(Ordering::SeqCst), false);
let foo = AtomicBool::new(true);
assert_eq!(foo.fetch_and(true, Ordering::SeqCst), true);
assert_eq!(foo.load(Ordering::SeqCst), true);
let foo = AtomicBool::new(false);
assert_eq!(foo.fetch_and(false, Ordering::SeqCst), false);
assert_eq!(foo.load(Ordering::SeqCst), false);
sourcepub fn and(&self, val: bool, order: Ordering)
pub fn and(&self, val: bool, order: Ordering)
Logical “and” with a boolean value.
Performs a logical “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 - MSP430:
and
instead of disabling interrupts
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::{AtomicBool, Ordering};
let foo = AtomicBool::new(true);
foo.and(false, Ordering::SeqCst);
assert_eq!(foo.load(Ordering::SeqCst), false);
let foo = AtomicBool::new(true);
foo.and(true, Ordering::SeqCst);
assert_eq!(foo.load(Ordering::SeqCst), true);
let foo = AtomicBool::new(false);
foo.and(false, Ordering::SeqCst);
assert_eq!(foo.load(Ordering::SeqCst), false);
sourcepub fn fetch_nand(&self, val: bool, order: Ordering) -> bool
pub fn fetch_nand(&self, val: bool, order: Ordering) -> bool
Logical “nand” with a boolean value.
Performs a logical “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::{AtomicBool, Ordering};
let foo = AtomicBool::new(true);
assert_eq!(foo.fetch_nand(false, Ordering::SeqCst), true);
assert_eq!(foo.load(Ordering::SeqCst), true);
let foo = AtomicBool::new(true);
assert_eq!(foo.fetch_nand(true, Ordering::SeqCst), true);
assert_eq!(foo.load(Ordering::SeqCst) as usize, 0);
assert_eq!(foo.load(Ordering::SeqCst), false);
let foo = AtomicBool::new(false);
assert_eq!(foo.fetch_nand(false, Ordering::SeqCst), false);
assert_eq!(foo.load(Ordering::SeqCst), true);
sourcepub fn fetch_or(&self, val: bool, order: Ordering) -> bool
pub fn fetch_or(&self, val: bool, order: Ordering) -> bool
Logical “or” with a boolean value.
Performs a logical “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::{AtomicBool, Ordering};
let foo = AtomicBool::new(true);
assert_eq!(foo.fetch_or(false, Ordering::SeqCst), true);
assert_eq!(foo.load(Ordering::SeqCst), true);
let foo = AtomicBool::new(true);
assert_eq!(foo.fetch_or(true, Ordering::SeqCst), true);
assert_eq!(foo.load(Ordering::SeqCst), true);
let foo = AtomicBool::new(false);
assert_eq!(foo.fetch_or(false, Ordering::SeqCst), false);
assert_eq!(foo.load(Ordering::SeqCst), false);
sourcepub fn or(&self, val: bool, order: Ordering)
pub fn or(&self, val: bool, order: Ordering)
Logical “or” with a boolean value.
Performs a logical “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 - MSP430:
bis
instead of disabling interrupts
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::{AtomicBool, Ordering};
let foo = AtomicBool::new(true);
foo.or(false, Ordering::SeqCst);
assert_eq!(foo.load(Ordering::SeqCst), true);
let foo = AtomicBool::new(true);
foo.or(true, Ordering::SeqCst);
assert_eq!(foo.load(Ordering::SeqCst), true);
let foo = AtomicBool::new(false);
foo.or(false, Ordering::SeqCst);
assert_eq!(foo.load(Ordering::SeqCst), false);
sourcepub fn fetch_xor(&self, val: bool, order: Ordering) -> bool
pub fn fetch_xor(&self, val: bool, order: Ordering) -> bool
Logical “xor” with a boolean value.
Performs a logical “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::{AtomicBool, Ordering};
let foo = AtomicBool::new(true);
assert_eq!(foo.fetch_xor(false, Ordering::SeqCst), true);
assert_eq!(foo.load(Ordering::SeqCst), true);
let foo = AtomicBool::new(true);
assert_eq!(foo.fetch_xor(true, Ordering::SeqCst), true);
assert_eq!(foo.load(Ordering::SeqCst), false);
let foo = AtomicBool::new(false);
assert_eq!(foo.fetch_xor(false, Ordering::SeqCst), false);
assert_eq!(foo.load(Ordering::SeqCst), false);
sourcepub fn xor(&self, val: bool, order: Ordering)
pub fn xor(&self, val: bool, order: Ordering)
Logical “xor” with a boolean value.
Performs a logical “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 - MSP430:
xor
instead of disabling interrupts
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::{AtomicBool, Ordering};
let foo = AtomicBool::new(true);
foo.xor(false, Ordering::SeqCst);
assert_eq!(foo.load(Ordering::SeqCst), true);
let foo = AtomicBool::new(true);
foo.xor(true, Ordering::SeqCst);
assert_eq!(foo.load(Ordering::SeqCst), false);
let foo = AtomicBool::new(false);
foo.xor(false, Ordering::SeqCst);
assert_eq!(foo.load(Ordering::SeqCst), false);
sourcepub fn fetch_not(&self, order: Ordering) -> bool
pub fn fetch_not(&self, order: Ordering) -> bool
Logical “not” with a boolean value.
Performs a logical “not” operation on 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::{AtomicBool, Ordering};
let foo = AtomicBool::new(true);
assert_eq!(foo.fetch_not(Ordering::SeqCst), true);
assert_eq!(foo.load(Ordering::SeqCst), false);
let foo = AtomicBool::new(false);
assert_eq!(foo.fetch_not(Ordering::SeqCst), false);
assert_eq!(foo.load(Ordering::SeqCst), true);
sourcepub fn not(&self, order: Ordering)
pub fn not(&self, order: Ordering)
Logical “not” with a boolean value.
Performs a logical “not” operation on 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 xor
instead ofcmpxchg
loop - MSP430:
xor
instead of disabling interrupts
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::{AtomicBool, Ordering};
let foo = AtomicBool::new(true);
foo.not(Ordering::SeqCst);
assert_eq!(foo.load(Ordering::SeqCst), false);
let foo = AtomicBool::new(false);
foo.not(Ordering::SeqCst);
assert_eq!(foo.load(Ordering::SeqCst), true);
sourcepub fn fetch_update<F>(
&self,
set_order: Ordering,
fetch_order: Ordering,
f: F,
) -> Result<bool, bool>
pub fn fetch_update<F>( &self, set_order: Ordering, fetch_order: Ordering, f: F, ) -> Result<bool, bool>
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
.
§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.
§Panics
Panics if fetch_order
is Release
, AcqRel
.
§Examples
use portable_atomic::{AtomicBool, Ordering};
let x = AtomicBool::new(false);
assert_eq!(x.fetch_update(Ordering::SeqCst, Ordering::SeqCst, |_| None), Err(false));
assert_eq!(x.fetch_update(Ordering::SeqCst, Ordering::SeqCst, |x| Some(!x)), Ok(false));
assert_eq!(x.fetch_update(Ordering::SeqCst, Ordering::SeqCst, |x| Some(!x)), Ok(true));
assert_eq!(x.load(Ordering::SeqCst), false);
sourcepub const fn as_ptr(&self) -> *mut bool
pub const fn as_ptr(&self) -> *mut bool
Returns a mutable pointer to the underlying bool
.
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+.
Trait Implementations§
source§impl Debug for AtomicBool
impl Debug for AtomicBool
source§impl Default for AtomicBool
impl Default for AtomicBool
source§impl<'de> Deserialize<'de> for AtomicBool
Available on crate feature serde
only.
impl<'de> Deserialize<'de> for AtomicBool
serde
only.source§fn deserialize<D>(deserializer: D) -> Result<Self, D::Error>where
D: Deserializer<'de>,
fn deserialize<D>(deserializer: D) -> Result<Self, D::Error>where
D: Deserializer<'de>,
source§impl From<bool> for AtomicBool
impl From<bool> for AtomicBool
source§impl Serialize for AtomicBool
Available on crate feature serde
only.
impl Serialize for AtomicBool
serde
only.