Re: [Boost-users] [multi-index] Container not safe against reentrant clear() / erase() ?

Subject: Re: [Boost-users] [multi-index] Container not safe against reentrant clear() / erase() ?
From: Sebastian Theophil (stheophil_at_[hidden])
Date: 2009-06-03 12:08:03

Hi Joaquin,

thanks for your prompt reply.
> 
> If I'm understanding this right, I think your design is flawed. You
say
> that CObjects
> detach themselves from g_multiindex when their refcount drops to 0,
> but:
> how can
> this count be zero if the CObject is still referenced from
> g_multiindex?

It seems I haven't expressed myself very clearly. Of course, the
refcount only drops to zero when g_multiindex is cleared. But assume
that a CObject can also be explicitly destroyed at any time. Obviously,
before destroying the CObject, the caller could explicitly remove the
CObject from the multi_index_container. This would need to be done
whenever a CObject is destroyed and sooner or later someone will forget
to do it. It seems much simpler to let the CObject dtor do the work of
removing all references to itself, as long as the container is safe
against "double deletion".

> This is simply an uncovered situation, and, IMHO, a very unusual one
> --in support
> of my view I can say I never got a report on this, and the lib's been
> around for
> 4.5 years.

I can't argue against that :-)

> 
> On the other hand, erasing inside erase() does work; 

What I do is erase() -> ~node() -> erase() and I would guess that
doesn't work for the same reason as before:
If the container has n elements, node deletion goes through the
following states

delete_node( node* x ) {
        // container has n nodes
        destroy(x)
        // container still has n nodes but x has been destroyed 
        reset left / right / parent pointers
        // container has n-1 nodes
}

Or is that wrong? 

What I'd like is something like

delete_node( node* x ) {
         reset left / right / parent pointers
          // container has n-1 nodes, x has not been destructed yet
       destroy(x)
}

In this implementation, the multi_index_container is never in an invalid
state. In the current implementation, elements contained in a container
cannot reliably make operations on the same container inside their
destructor. The dtor may e.g. destroy the internal data structures used
to order the nodes. What if one node's dtor would like to remove a set
of dependent elements from the container as well? 

Regards,
Sebastian

--
Sebastian Theophil . stheophil_at_[hidden]
Software Engineer
 
think-cell Software GmbH . Invalidenstr. 34 . 10115 Berlin, Germany 
http://www.think-cell.com . phone [phone] . toll-free (US) [phone]
Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl . Amtsgericht Berlin-Charlottenburg, HRB 85229