-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Server Programmability
-
Programmability 2025-06-23, Programmability 2025-07-07
-
None
-
3
-
TBD
-
None
-
None
-
None
-
None
-
None
-
None
We can improve VersionedValue by a new API that accepts a callback and allows user-defined logic to peak at the current value and optionally updating it if needed. This allows enforcing external versioning logic without requiring an additional level of synchronization, as VersionedValue is thread-safe, but doesn't have any mechanism to understand the versioning semantics for the stored value and always ensure that V2 is more recent than V1. Below is my suggestion on how this new API can be implemented:
template <typename ValueType, typename MutexType = stdx::mutex, typename LockPolicy = versioned_value_detail::DefaultLockPolicy> class VersionedValue { public: ... void peekAndMaybeUpdate(std::function<std::shared_ptr<ValueType>(const std::shared_ptr<ValueType>&)> cb) { auto lk = _lockPolicy.makeExclusiveLock(_mutex); if (auto maybeNewValue = cb(_current)) { _update(lk, std::move(maybeNewValue)); } } void update(std::shared_ptr<ValueType> newValue) { auto lk = _lockPolicy.makeExclusiveLock(_mutex); _update(lk, std::move(newValue)); } ... private: void _update(WithLock, std::shared_ptr<ValueType> newValue) { _version.fetchAndAdd(1); _current = std::move(newValue); } ... };
Users can implement cb such that it checks the current (user-defined) version of ValueType and only resets _current (i.e. returns a non-null value) if it will be updated to a more recent version.
- is depended on by
-
SERVER-106243 Use the new VersionedValue api to remove TargetedHostsCacheManager's mutex
-
- Backlog
-