[Insight-developers] SmartPointers without thread safety.

[Luis Ibanez]

Jim,

I'm tracking down the memory leaks in the Mesh and
go to the following point:

The Mesh is capable of simulating that the topology of
the mesh is represented by a complete K-complex,
that is, for every ND cell, their (N-1) D, (N-2)D, (N-3),
..., 1D, 0D boundaries are assumed to be explicitly
represented on the set of cells.  However for the sake
of memory usage this structure is simulated by building
the boundaries on the fly when they are requested instead
for actually creating them from the start.

For example in the typical case of a triangulated surface
in 3D, the user can ask the mesh to produce the 1D face
of a 2D triangular cell.  This 1D face can either exists
already as a 1D cell in the CellContainer  or can be created
on the fly.

Before the modifications of the Mesh for supporting
FEM polymorphic cells, all the cells were deriving from
itk::LighObject and using SmartPointers.      We remove
the derivation from LightObject because the Mutex lock
used around reference counting updates impossed a
penalty in performance for every cell access.

However.... the functionality of creating boundaries on
the fly rely heavily on the use of SmartPointers because
these cells are constructed and left on their own for
destruction.  With the smart pointers that happened
naturally when the ref.count get to zero.

In the new setting the fate of every Boundary cells it is
very ambiguous. Some can  have been created from
arrays while others can have been allocated dynamically....
and it becomes very hard (if not impossible) to find a consistent
way of releasing their memory.


So.....
We got to the following dilema :

Could we have for the cells the nice part of the SmartPointers
(namely the automatic destruction of objects) without having
to pay the performance penalty of the Mutex ?

It seems that if we create a non-thread-safe SmartPointer
that should be possible.  It will be basically a double of the
SmartPointer from which the Mutex locks will be removed.
Probably both Smart Pointers deriving from a common
class in order to avoid code duplication.


The consequence is that It will not be possible to access
a cell from two different threads... and that's Ok . We can
add a Doxygen \warning in the appropiated places to let
users know that this is the case.


What would you suggest  as a viable option ?


Thanks


Luis