[Insight-developers] SmartPointers without thread safety.

[Miller, James V (CRD)]

This is an issue I want to make sure that we handle correctly.
I think in general it will be difficult to ensure that cells are 
not accessed from multiple threads. 

The common hurdle is going to be in an application where the
user interface is one thread and another thread (or threads)
is used for processing.  In this circumstance, I don't think
there is any way to make sure the processing thread doesn't
delete a cell that the GUI is still trying to display.

So I think the "Doctor it hurts when I do this, then don't so that"
approach really handcuffs the application writer.  In VTK apps,
I have to be very very very careful to make sure that I don't have
multiple threads trying to access the same data objects. This is
doable but it requires the application writer REALLY understand
what API calls are thread safe and what API calls are not 
thread safe.

VXL has a "shared pointer" which looks seems to work like a 
smart pointer except the reference count is held in the pointer
and not the object.  This may be an option for having smart pointer
type capabilities on cells.  The overhead of the reference count
would only be associated with those cells that have been "exported".

This does not solve the thread safety issue.



-----Original Message-----
From: William A. Hoffman [mailto:bill.hoffman@kitware.com]
Sent: Monday, April 01, 2002 9:26 PM
To: Luis Ibanez; Insight Developers; Miller, James V (CRD)
Subject: Re: [Insight-developers] SmartPointers without thread safety.


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