arc_swap

Module strategy

source
Expand description

Strategies for protecting the reference counts.

There are multiple algorithms how to protect the reference counts while they’re being updated by multiple threads, each with its own set of pros and cons. The DefaultStrategy is used by default and should generally be the least surprising option. It is possible to pick a different strategy.

For now, the traits in here are sealed and don’t expose any methods to the users of the crate. This is because we are not confident about the details just yet. In the future it may be possible for downstream users to implement their own, but for now it is only so users can choose one of the provided.

It is expected that future strategies would come with different capabilities and limitations. In particular, some that are not “tight” in the cleanup (delay the cleanup) or not support the compare and swap operations.

Currently, we have these strategies:

§Testing

Formally, the RwLock<()> may be used as a strategy too. It doesn’t have the performance characteristics or lock-free guarantees of the others, but it is much simpler and contains less unsafe code (actually, less code altogether). Therefore, it can be used for testing purposes and cross-checking.

Note that generally, using RwLock<Arc<T>> is likely to be better performance wise. So if the goal is to not use third-party unsafe code, only the one in std, that is the better option. This is provided mostly for investigation and testing of ArcSwap itself or algorithms written to use ArcSwap.

This is not meant to be used in production code.

Traits§

  • CaS
    An extension of the Strategy, allowing for compare and swap operation.
  • Strategy
    A strategy for protecting the reference counted pointer T.

Type Aliases§