[Insight-developers] SmartPointers without thread safety.

[Miller, James V (CRD)]

Another point of clarification:

(I was just reading through some other smart pointer implementations).

I think in our design we are promoting a certain restricted type
of thread safety.

When we have multiple threads, we are allowing any of the threads
to read the data. And we say our smart pointer is thread safe in that
the reference count is protected.  We are not protecting the data
pointed to by the smart pointer from simultaneous writes or read/write
combinations. In other words, if one thread is writing
to a shared object and another thread is reading from the shared object 
the read thread could get "corrupted" data.  It would be up to the 
application to manage simultaneous read/write access to this "shared"
resource.

There are smart pointer implementations that will completely manage
the access to the shared resource; however, this implies a large overhead.

On a side note: Does anyone know the performance difference on Windows
between using CriticalSections vs InterlockedIncrement/InterlockedDecrement?



-----Original Message-----
From: Miller, James V (CRD) 
Sent: Tuesday, April 02, 2002 8:37 AM
To: 'William A. Hoffman'; Luis Ibanez; Insight Developers
Subject: RE: [Insight-developers] SmartPointers without thread safety.


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