[Insight-developers] itk::LightObject non-threaded

Luis Ibanez luis.ibanez@kitware.com
Thu, 04 Apr 2002 20:28:23 -0500


Jim,

Following up on your clarification of the itkLightObject
SmartPointer and their relation with the Mutex....

How about adding a class "itkLightObjectNonThreaded" ?

It will basically be the itkLightObject without the Mutex
in the Register/Unregister methods (and without the
mutex lock ivar itself), only the reference counter.

Objects deriving from this new class will still be able to
use smart pointers and enjoy of the convenience of
automatic memory collection while still being fast in
pointer copying.

BTW it is worth to clarify that the access itself is *not*
penalized by the mutexlock, only the copy of the SmartPointer
into another SmartPointer is.  Dereferencing the object doesn't
require to modify the reference counting and it is done by an
inlined method in the SmartPointer.  Any access of type:

            smartPointer->      or       *smartPointer

should be as direct as using the normal pointer.
(except when compiling with debugging, which will prevent
this functions from being inlined...)


In order to avoid code duplication with this new
itk::LightObjectNonThreaded  class we can make:

     itk::LightObject    

          derive from    

   itk::LightObjectNonThreaded

that will leave itk::LightObject with only the additional
code required for the Mutexlock: namely the mutexlock
ivar and the overload for the virtual methods:

        Register() / UnRegister() / SetReferenceCount()


With this combination, classes that are expected to be shared
from diferent threads should derive from itk::LightObject (or
itk::Object)  while classes that are limited to be used from inside
a single thread will derive from itk::LightObjectNonThreaded
and still be able to use SmartPointers as strategy for memory
collection.  Current SmartPointers could be used without change.


How do you find this option ?


Luis