[Insight-developers] SmartPointers without thread safety.
Luis Ibanez
luis.ibanez@kitware.com
Wed, 03 Apr 2002 08:52:41 -0500
Jim,
Thanks for the clarifications on the
SmartPointer/LigthObject use of the Mutex.
How about adding to LightObject something
like "SetThreadSafe(bool)" for setting a
boolean ivar and according to it do the
MutexLock or not. That will keep the current
code almost unmodified and still allow to
improve performance for the cases in which
multiple threads are not being used.
You also raised an important point: the
access to the object data itself is not
thread safe, only the reference counting is.
So if somebody want to share cells between
two threads he has to take care of the
mutual exclusion.
Luis
===========================================
Miller, James V (CRD) wrote:
> 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
>>
>
>