#memory #pinned #vec #array #vector

no-std orx-pinned-vec

PinnedVec trait defines the interface for vectors which guarantee that elements added to the vector are pinned to their memory locations unless explicitly changed

41 releases (27 stable)

3.10.0 Sep 20, 2024
3.7.0 Aug 28, 2024
3.2.0 Jul 25, 2024
2.12.0 Jun 28, 2024
0.4.3 Sep 8, 2023

#680 in Data structures

Download history 406/week @ 2024-08-03 356/week @ 2024-08-10 464/week @ 2024-08-17 648/week @ 2024-08-24 652/week @ 2024-08-31 1045/week @ 2024-09-07 1015/week @ 2024-09-14 988/week @ 2024-09-21 758/week @ 2024-09-28 680/week @ 2024-10-05 501/week @ 2024-10-12 596/week @ 2024-10-19 660/week @ 2024-10-26 885/week @ 2024-11-02 744/week @ 2024-11-09 750/week @ 2024-11-16

3,081 downloads per month
Used in 12 crates (11 directly)

MIT license

88KB
1.5K SLoC

orx-pinned-vec

orx-pinned-vec crate orx-pinned-vec documentation

PinnedVec trait defines the interface for vectors which guarantee that elements added to the vector are pinned to their memory locations unless explicitly changed.

A. Pinned Elements Guarantee

A PinnedVec guarantees that positions of its elements do not change implicitly.

To be specific, let's assume that a pinned vector currently has n elements:

Method Expected Behavior
push(new_element) does not change the memory locations of the n elements
extend_from_slice(slice) does not change the memory locations of the first n elements
insert(a, new_element) does not change the memory locations of the first a elements, where a <= n; elements to the right of the inserted element might be changed, commonly shifted to right
pop() does not change the memory locations of the first n-1 elements, the n-th element is removed
remove(a) does not change the memory locations of the first a elements, where a < n; elements to the right of the removed element might be changed, commonly shifted to left
truncate(a) does not change the memory locations of the first a elements, where a < n

PinnedVec trait on its own cannot provide the pinned element guarantee; hence, it could be considered as a marker trait.

However, this crate additionally provides the test function to assert these guarantees:

pub fn test_pinned_vec<P: PinnedVec<usize>>(pinned_vec: P, test_vec_len: usize) {
    // ...
}

This function performs an extensive test on the specific implementation P and fails if any of the above guarantees is not provided.

Note that std::vec::Vec does not provide the pinned elements during growth guarantee. You may find a wrapper struct JustVec which is nothing but the standard vec here: src/pinned_vec_tests/test_all.rs. As expected, test_pinned_vec method fails for this struct.

B. Motivation

There are various situations where pinned elements are critical.

  • It is critical in enabling efficient, convenient and safe self-referential collections with thin references, see SelfRefCol for details, and its special cases such as LinkedList.
  • It is important for concurrent programs as it eliminates safety concerns related with elements implicitly carried to different memory locations. This helps reducing and dealing with the complexity of concurrency, and leads to efficient concurrent data structures. See ConcurrentIter, ConcurrentBag or ConcurrentOrderedBag for such concurrent data structures which are conveniently built on the pinned element guarantees of pinned vectors.
  • It is essential in allowing an immutable push vector; i.e., ImpVec. This is a very useful operation when the desired collection is a bag or a container of things, rather than having a collective meaning. In such cases, ImpVec allows avoiding certain borrow checker complexities, heap allocations and wide pointers such as Box or Rc or etc.

C. Implementations

SplitVec and FixedVec are two efficient implementations.

License

This library is licensed under MIT license. See LICENSE for details.

Dependencies