Re: [boost] intrusive_ptr design question

Subject: Re: [boost] intrusive_ptr design question
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-07-06 15:31:46

Zachary Turner wrote:
> On Mon, Jul 6, 2009 at 10:50 AM, Stewart,
> Robert<Robert.Stewart_at_[hidden]> wrote:
> > Zachary Turner wrote:
> >> That's correct.  The way I have envisioned is analagous to the
> >> way shared_ptr allows you to specify a custom deleter.
> >> Whenever a copy is made, the new copy gets the same deleter.
> >> That way all copies agree on the deletion semantics.  As long
> >> as all copies of the shared pointer that refer to the same
> >> underlying instance of pointed-to object agree on reference
> >> counting semantics, everything should be ok right?
> >
> > object.  Manipulating a reference count, tens, hundreds, or
> > more times, exposes a much greater danger.  Yes, copies will
> > agree on how to manipulate the reference count, but the same
> > memory can be referenced by separately constructed,
> > non-copied smart pointer instances.
>
> Could you elaborate a bit more?  I'm not sure I understand.  Of
> course it's up to the programmer to specify correct reference
> counting functions and construct shared_ptr instances correctly
> or else the behavior will be undefined.  Are you saying that

An interface that permits ready misuse is questionable.

> the problem would be with something like this?
>
> T* t = new T();
>
> shared_ptr<T> ptr_t(t, multi_threaded_ref_counter());
> shared_ptr<T> ptr_t2(t);
>
> Causing the instance to be deleted twice eventually?  If so, how

No.  More below.

> is that different from:
>
> T* t = new T();
>
> shared_ptr<T> ptr_t(t);
> shared_ptr<T> ptr_t2(t);

That can be found using memory analysis tools which reveal the double delete.

> Or for that matter, from:
>
> T* t = new T();
>
> shared_ptr<T> ptr_t(t);
> delete t;

Likewise.

My concern is the following, assuming "counter" is a class that supports your notion of construction time specification of referencing counting:

   int * x(new int);
   counter<int> a(x, unsafe_ref_count); // not thread safe
   ...
   counter<int> b(x, safe_ref_count); // thread safe

In these cases, assume that (un)safe_ref_count package the reference counting logic in some handy way not specified ATM.

Note that threaded code assumes it can access x's memory safely, using b, because of using safe_ref_count.  Also note that other code can use a to manipulate x's reference count and access x's memory at the same time.  That means that b's memory and reference count are not thread safe after all.  This same effect can come about in a number of ways.  If you copy a or b, the copy will use the same reference counting scheme, of course.  However, a and b are the same type, so they can interoperate in ways that are either unexpected or cannot be discovered until runtime.

You said (or implied, I don't recall offhand) that you'd supply the increment/decrement ref count functions to the constructor.  That means that (un)safe_ref_count actually represent a pair of function pointers.  Obviously, that interface precludes optimization opportunities -- at least in many cases -- and permits pairing the wrong functions.

You could supply an object with such a pair of functions on it that counter can call.  By grouping the functions in a UDT, you eliminate the chance of incorrect pairing and increase the chance of optimization.

OTOH, if you embed the reference counting behavior into the type of the smart pointer -- counter<int, safe_ref_counter>, for example -- you reduce the opportunities of different parts of the code using different reference counting behavior for the same memory.  The compiler can catch cases of misuse.  Furthermore, the policy class groups the function pair in one type, thus eliminating the chance to combine them incorrectly.

Boost.SmartPtr currently traffics in counter<int> types (shared_ptr<T>, intrusive_ptr<T>, etc.) and not in counter<int,policy> types, thus safe usage of your idea cannot be added to those types and must be done with a policy class in a new smart pointer type.

HTH,

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.