Although we expose the stability frontiers by a set of callbacks passed to the Derecho group constructor, application code inside a subgroup type wrapped in Replicated<T> also needs access to those frontiers. This patch exposes those frontiers through a set of methods in the group handle available to Replicated<T>.
Replicated<T>::get_global_persistence_frontier()
Replicated<T>::get_global_verified_frontier()
wait_for_global_persistence_frontier()
wait_for_global_verified_frontier() is left for future, when we really need it. The mechanism should be the same as that of wait_for_global_persistence_frontier().
I've tested it using the Cascade branch refactor_get_api and it works.
@etremel Thanks for reviewing. I just documented those internal APIs in multicast_group.hpp. And yes, multiple threads will access those counters, that's why I use atomic counters.
Although we expose the stability frontiers by a set of callbacks passed to the Derecho group constructor, application code inside a subgroup type wrapped in
Replicated<T>
also needs access to those frontiers. This patch exposes those frontiers through a set of methods in the group handle available toReplicated<T>
.Replicated<T>::get_global_persistence_frontier()
Replicated<T>::get_global_verified_frontier()
wait_for_global_persistence_frontier()
wait_for_global_verified_frontier()
is left for future, when we really need it. The mechanism should be the same as that ofwait_for_global_persistence_frontier()
.I've tested it using the Cascade branch
refactor_get_api
and it works.