[SmartPtr] intrusive_ref_counter CounterPolicyT requirements API?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[SmartPtr] intrusive_ref_counter CounterPolicyT requirements API?

Boost - Dev mailing list
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#intrusive_ref_counter

"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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [SmartPtr] intrusive_ref_counter CounterPolicyT requirements API?

Boost - Dev mailing list
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#intrusive_ref_counter
>
> "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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [SmartPtr] intrusive_ref_counter CounterPolicyT requirements API?

Boost - Dev mailing list
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/678a544d27d016204c6aed6403b1ffdf0b021d1b/include/boost/smart_ptr/detail/atomic_count.hpp#L33-L43

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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [SmartPtr] intrusive_ref_counter CounterPolicyT requirements API?

Boost - Dev mailing list
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/678a544d27d016204c6aed6403b1ffdf0b021d1b/include/boost/smart_ptr/detail/atomic_count.hpp#L33-L43 
>
>
> 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).

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [SmartPtr] intrusive_ref_counter CounterPolicyT requirements API?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, Dec 4, 2020 at 12:39 PM Andrey Semashev via Boost <
[hidden email]> 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#intrusive_ref_counter
> >
> > "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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost