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

[Miller, James V (Research)]

I am not sure whether this new class needs to be 
in the hierrarchy or not. If it is in the hierarchy
I think we need to work on the names a bit.

itkReferenceCountedObject (has reference count and Register()/UnRegister())
         |
itkProtectedReferenceCountedObject (has the mutex and protected versions of Register()/UnRegister())
         |
   itkLightObject
         |
     itkObject


In this scheme, LightObject might end up being empty.

Here's an idea I like better:

The only thing that accesses the Register/UnRegister
methods is the SmartPointer class. So how about 
having a second SmartPointer class that calls a 
different pair of "Register/UnRegister" methods 
that bypasses the mutex.

We had talked at the last meeting that every method
that currently returns a smart pointer could be 
changed to return a real pointer to bypass some of the
mutex overhead in creating and destroying smart pointers
on the stack. If someone wanted to hold onto
the reference they would assign it a smart pointer.
If we have two smart pointer classes, they could choose
whether they wanted to use a smart pointer that used 
a mutex to modify the reference count or not.

This may useful for the following case as well:

I grab some data out of a dataset and use the nonmutex
versions of smart pointers because I am not doing any
threading.  I pass this information to another routine
in the toolkit that does thread its calculations but I 
didn't know that it threaded its calculations.  Internally,
that second method would have stored this information in
a mutex smart pointer since it knew it was threading...






-----Original Message-----
From: Luis Ibanez [mailto:luis.ibanez@kitware.com]
Sent: Thursday, April 04, 2002 8:28 PM
To: Miller, James V (Research); Insight Developers
Subject: itk::LightObject non-threaded



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