[SmartPtr] intrusive_ref_counter CounterPolicyT requirements API?
Hi Boost, We're considering implementing our own atomic ref count for `intrusive_ref_count` [*]. A question came up. Is the `CounterPolicyT` template parameter a stable extension hook, or are users expected to strictly stick to the two provided policies of `thread_unsafe_counter` and `thread_safe_counter`? I can see that under the hood, these policy structs are trivially simple and we can just do it, but the question is really about whether the lack of documentation implies that it's a private boost detail. From https://www.boost.org/doc/libs/1_74_0/libs/smart_ptr/doc/html/smart_ptr.html... "The second parameter is a policy that defines the nature of the reference counter. The library provides two such policies: thread_unsafe_counter and thread_safe_counter." Thanks for your time, Billy Donahue [*] Incidentally we want to increment with memory order relaxed instead of acq_rel. -- ǝnɥɐuop ʎllıq
On 12/4/20 7:11 PM, Billy via Boost wrote:
Hi Boost,
We're considering implementing our own atomic ref count for `intrusive_ref_count` [*]. A question came up. Is the `CounterPolicyT` template parameter a stable extension hook, or are users expected to strictly stick to the two provided policies of `thread_unsafe_counter` and `thread_safe_counter`? I can see that under the hood, these policy structs are trivially simple and we can just do it, but the question is really about whether the lack of documentation implies that it's a private boost detail.
From https://www.boost.org/doc/libs/1_74_0/libs/smart_ptr/doc/html/smart_ptr.html...
"The second parameter is a policy that defines the nature of the reference counter. The library provides two such policies: thread_unsafe_counter and thread_safe_counter."
As an original implementor of the component, I did not intend this to be an extension point. If I wanted to customize reference counting, I would probably not use intrusive_ref_counter and instead implement intrusive_ptr_add_ref/release or a similar base class to my requirements.
[*] Incidentally we want to increment with memory order relaxed instead of acq_rel.
This would probably be a good optimization in atomic_count.
Andrey Semashev wrote:
[*] Incidentally we want to increment with memory order relaxed instead of acq_rel.
This would probably be a good optimization in atomic_count.
atomic_count can't do this because it doesn't have enough knowledge about the context in which it's used. https://github.com/boostorg/smart_ptr/blob/678a544d27d016204c6aed6403b1ffdf0... In principle you can use negative values for the count, again destroying on zero. I could have specified ++a to be relaxed, but it is what it is at this point.
On 12/4/20 8:44 PM, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
[*] Incidentally we want to increment with memory order relaxed instead > of acq_rel.
This would probably be a good optimization in atomic_count.
atomic_count can't do this because it doesn't have enough knowledge about the context in which it's used.
https://github.com/boostorg/smart_ptr/blob/678a544d27d016204c6aed6403b1ffdf0...
In principle you can use negative values for the count, again destroying on zero.
I could have specified ++a to be relaxed, but it is what it is at this point.
atomic_count is formally an implementation detail of Boost.SmartPtr, so you can define it as you see fit. If it is only used as a reference counter, you could make it increment with relaxed semantics. Or add a separate member with such behavior (but then the operator++ would become unused).
On Fri, Dec 4, 2020 at 12:39 PM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
On 12/4/20 7:11 PM, Billy via Boost wrote:
Hi Boost,
We're considering implementing our own atomic ref count for `intrusive_ref_count` [*]. A question came up. Is the `CounterPolicyT` template parameter a stable extension hook, or are users expected to strictly stick to the two provided policies of `thread_unsafe_counter` and `thread_safe_counter`? I can see that under the hood, these policy structs are trivially simple and we can just do it, but the question is really about whether the lack of documentation implies that it's a private boost detail.
From
https://www.boost.org/doc/libs/1_74_0/libs/smart_ptr/doc/html/smart_ptr.html...
"The second parameter is a policy that defines the nature of the
reference
counter. The library provides two such policies: thread_unsafe_counter and thread_safe_counter."
As an original implementor of the component, I did not intend this to be an extension point. If I wanted to customize reference counting, I would probably not use intrusive_ref_counter and instead implement intrusive_ptr_add_ref/release or a similar base class to my requirements.
Yes, that's what we've been doing thus far. I guess we'll carry on doing that. Thanks Andrey and Peter.
[*] Incidentally we want to increment with memory order relaxed instead of acq_rel.
This would probably be a good optimization in atomic_count.
-- ǝnɥɐuop ʎllıq
participants (3)
-
Andrey Semashev -
Billy -
Peter Dimov