List:Falcon Storage Engine« Previous MessageNext Message »
From:Kevin Lewis Date:October 6 2008 9:40pm
Subject:Re: Understanding RefCounts in Falcon
View as plain text  
 >Vladislav Vaintroub wrote:
> a) string tmp  = object1->object2->object3->str; //copy constructor
> involved
> b) string &tmp = object1->object2->object3->str; //no copy, tmp can be
> changed
> c) const string &tmp = object1->object2->object3->str; // no copy, tmp
> is
> immutable
> 
> In case b) and c) no copy is involved.
> 
> I believe there are basically 3 cases where copies can be created:
> 1) passing via function parameter -> copy/increment can and must be avoided
> 2) tmp copy inside a function -> copy/increment can and must be avoided
> 3) passing object to the constructor of another object -> copy/increment may
> be done. Depends on lifecycle of another object, if it can outlive current
> object - copy necessary , if not, copy not necessary.
> 4) reading object from containers (list/queue) shared between threads ->
> copy/increment must be done
> 
> Can you think of something else?. 

Both 3 and 4 involve holding a pointer to an object for longer periods 
of time.  And you seem to think that the code could be designed with 
smart pointers so that the unnecessary increments can be avoided.  I 
would love to see an example of that.

I think the DeferredIndex objects are a great place to start.  The long 
term locations for pointers to a DI object are;

Index:: 	Queue<DeferredIndex>	deferredIndexes;
Transaction::	DeferredIndex	*deferredIndex;
DeferredIndexWalker::	DeferredIndex	*deferredIndex;
WalkDeferred::	DeferredIndex	*deferredIndex;

Currently the Index::deferredIndexes location is not being refcounted. 
Chris and I think it probably should, but no bugs indicate the need for 
it.  The transaction is the primary owner and the code is prepared, 
after Bug#39846, for the index to go away sooner than the transaction.

Anyway, that would be a great place to propose a smart pointer solution 
for us to evaluate.  If it has the same number of interlocked increments 
and decrements as the current code, then it should be more stable and 
maintainable.

Kevin

Thread
Understanding RefCounts in FalconKevin Lewis6 Oct
  • RE: Understanding RefCounts in FalconVladislav Vaintroub6 Oct
    • Re: Understanding RefCounts in FalconMARK CALLAGHAN6 Oct
      • RE: Understanding RefCounts in FalconVladislav Vaintroub6 Oct
      • Re: Understanding RefCounts in FalconKevin Lewis6 Oct
        • RE: Understanding RefCounts in FalconVladislav Vaintroub6 Oct
          • Re: Understanding RefCounts in FalconKevin Lewis6 Oct
            • RE: Understanding RefCounts in FalconVladislav Vaintroub7 Oct
              • Re: Understanding RefCounts in FalconJim Starkey7 Oct