Type Definition arc_swap::strategy::DefaultStrategy

source · [−]
pub type DefaultStrategy = HybridStrategy<DefaultConfig>;
Expand description

The default strategy.

It is used by the type aliases ArcSwap and ArcSwapOption. Only the other strategies need to be used explicitly.

Performance characteristics

  • It is optimized for read-heavy situations, with possibly many concurrent read accesses from multiple threads. Readers don’t contend each other at all.
  • Readers are wait-free (with the exception of at most once in usize::MAX / 4 accesses, which is only lock-free).
  • Writers are lock-free.
  • Reclamation is exact ‒ the resource is released as soon as possible (works like RAII, not like a traditional garbage collector; can contain non-'static data).

Each thread has a limited number of fast slots (currently 8, but the exact number is not guaranteed). If it holds at most that many Guards at once, acquiring them is fast. Once these slots are used up (by holding to these many Guards), acquiring more of them will be slightly slower, but still wait-free.

If you expect to hold a lot of “handles” to the data around, or hold onto it for a long time, you may want to prefer the load_full method.

The speed of the fast slots is in the ballpark of locking an uncontented mutex. The advantage over the mutex is the stability of speed in the face of contention from other threads ‒ while the performance of mutex goes rapidly down, the slowdown of running out of held slots or heavy concurrent writer thread in the area of single-digit multiples.

The ballpark benchmark figures (my older computer) are around these, but you’re welcome to run the benchmarks in the git repository or write your own.

  • Load (both uncontented and contented by other loads): ~30ns
  • load_full: ~50ns uncontented, goes up a bit with other load_full in other threads on the same Arc value (~80-100ns).
  • Loads after running out of the slots ‒ about 10-20ns slower than load_full.
  • Stores: Dependent on number of threads, but generally low microseconds.
  • Loads with heavy concurrent writer (to the same ArcSwap): ~250ns.