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:
DefaultStrategy(this one is used implicitly)RwLock<()>
§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§
- An extension of the
Strategy, allowing for compare and swap operation. - A strategy for protecting the reference counted pointer
T.
Type Aliases§
- The default strategy.