You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ServiceReferenceBase owns the ServiceReferenceBasePrivate object and holds an atomic raw pointer to it.
The underlying ServiceReferenceBasePrivate object holds an atomic ref count that indicates how many ServiceReferenceBase objects refer to it.
When a ServiceReference's operation makes this ref count zero, it deletes the underlying ServiceReferenceBasePrivate object.
The only thing we guarantee about the underlying ServiceReferenceBasePrivate object is assignment and copying are thread-safe.
Can this be replaced by a shared_ptr, which solves the same problem elegantly?
My guess as to the reason why shared_ptr wasn't chosen is that shared_ptrs are only partially thread-safe - the control block is thread-safe but accessing the actual resource is not thread-safe. But, we do have C++11-compatible atomic_* free functions specialized for shared_ptrs that guarantee that the underlying resource can be safely accessed in a multi-threaded setting (http://en.cppreference.com/w/cpp/memory/shared_ptr/atomic)
Pros:
Idiomatic & Modern.
Eliminates raw pointer, manual ref counting and automates destruction
ServiceReferenceBasePrivate and ServiceRegistrationBase each hold a raw pointer to the ServiceRegistrationBasePrivate object
In turn, the ServiceRegistrationBasePrivate object has a reference count to indicate how many ServiceReferenceBasePrivate and ServiceRegistrationBase objects refer to it.
When the reference count becomes zero, one of the ServiceReferenceBasePrivate and ServiceRegistrationBase object is responsible for deleting the ServiceRegistrationBasePrivate object.
Similarly, can't this mechanism can be replaced by shared_ptrs in both ServiceReferenceBasePrivate and ServiceRegistrationBase classes? i.e.
I need to read and think about this in more detail later. Just a quick note: std::shared_ptr wasn't used before because the code predates C++11 support in the code-base. I would love to see it being replaced with something more idiomatic, if possible.
ServiceReferenceBasePrivate
The only thing we guarantee about the underlying ServiceReferenceBasePrivate object is assignment and copying are thread-safe.
Can this be replaced by a shared_ptr, which solves the same problem elegantly?
My guess as to the reason why shared_ptr wasn't chosen is that shared_ptrs are only partially thread-safe - the control block is thread-safe but accessing the actual resource is not thread-safe. But, we do have C++11-compatible atomic_* free functions specialized for shared_ptrs that guarantee that the underlying resource can be safely accessed in a multi-threaded setting (http://en.cppreference.com/w/cpp/memory/shared_ptr/atomic)
Pros:
Cons:
Key Changes:
In ServiceReferenceBase,
In ServiceReferenceBasePrivate
-std::atomic<int> ref;
Additionally, there will be changes in the code to use atomic_* free functions when accessing the underlying resource.
See also: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4058.pdf (Appendix)
ServiceRegistrationBasePrivate
Similarly, can't this mechanism can be replaced by shared_ptrs in both ServiceReferenceBasePrivate and ServiceRegistrationBase classes? i.e.
In ServiceRegistrationBase,
In ServiceReferenceBasePrivate,
In ServiceRegistrationBasePrivate,
-std::atomic<int> ref;
And other related changes.
The text was updated successfully, but these errors were encountered: