orx_concurrent_vec/exclusive.rs
1use crate::{ConcurrentVec, elem::ConcurrentElement};
2use orx_pinned_vec::IntoConcurrentPinnedVec;
3
4impl<T, P> ConcurrentVec<T, P>
5where
6 P: IntoConcurrentPinnedVec<ConcurrentElement<T>>,
7{
8 /// Clears the concurrent bag.
9 pub fn clear(&mut self) {
10 unsafe { self.core.clear(self.core.state().len()) };
11 }
12
13 /// Note that [`ConcurrentVec::maximum_capacity`] returns the maximum possible number of elements that the underlying pinned vector can grow to without reserving maximum capacity.
14 ///
15 /// In other words, the pinned vector can automatically grow up to the [`ConcurrentVec::maximum_capacity`] with `write` and `write_n_items` methods, using only a shared reference.
16 ///
17 /// When required, this maximum capacity can be attempted to increase by this method with a mutable reference.
18 ///
19 /// Importantly note that maximum capacity does not correspond to the allocated memory.
20 ///
21 /// Among the common pinned vector implementations:
22 /// * `SplitVec<_, Doubling>`: supports this method; however, it does not require for any practical size.
23 /// * `SplitVec<_, Linear>`: is guaranteed to succeed and increase its maximum capacity to the required value.
24 /// * `FixedVec<_>`: is the most strict pinned vector which cannot grow even in a single-threaded setting. Currently, it will always return an error to this call.
25 ///
26 /// # Safety
27 /// This method is unsafe since the concurrent pinned vector might contain gaps. The vector must be gap-free while increasing the maximum capacity.
28 ///
29 /// This method can safely be called if entries in all positions 0..len are written.
30 pub fn reserve_maximum_capacity(&mut self, new_maximum_capacity: usize) -> usize {
31 unsafe {
32 self.core
33 .reserve_maximum_capacity(self.core.state().len(), new_maximum_capacity)
34 }
35 }
36}