[Insight-developers] SmartPointers without thread safety.

[William A. Hoffman]

The mutex is not in the smart pointer, but rather in 
itkLightObject::Register, so it
is not possible to make a non-thread save smart pointer without adding a 
non-thread
save register/unregister to LightObject.

Along those lines, the mutex lock is adding 4 bytes to every itk object.
Perhaps we should re-think this some.   I guess VTK gets away with this,
by documenting that it is not safe to call Register/Unregister in threaded 
functions.
We could do the same for ITK, and say that you have to use real pointers and
not smart pointers in threaded functions.


-Bill

At 08:36 PM 4/1/2002 -0500, Luis Ibanez wrote:

>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
>
>
>
>_______________________________________________
>Insight-developers mailing list
>Insight-developers@public.kitware.com
>http://public.kitware.com/mailman/listinfo/insight-developers