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

[Luis Ibanez]

Jim,

I like the option you mention of having a second
SmartPointer instead of adding an itkLigthObject
non-threaded.

Your option of the additional SmartPointer is
interesting because after all the decision of
protecting the reference counting is done by the
user of the class who should be aware of the use
of threads.  It is not part of the nature of the
object being referenced.

The option of returning normal pointers instead
of SmartPointers will make easy for users to select
how they want to manage the access to the particular
returned object.  It also has the advantage that
the code using these methods doesn't have to be
changed.

My only concern with returning normal pointers come
from the current problems we are experiencing with
the itkMesh and is : How to make sure that somebody
is made responsible for releasing memory ?.

We can probably deal with that by never receiving the
normal pointer into another normal pointer but always
using either:

- SmartPointer (the new non-thread safe,
                 which doesn't call the mutex)

or

- ThreadSafeSmartPointer (basically the current SmartPointer)

to manage the returned object.

That allows to create objects with New() and be
confident that they will be destroyed when necessary.

Otherwise, keeping track of how to delete the objects
can get pretty messy.


   Luis


=================================================

Miller, James V (Research) wrote:
> 
> 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...
> 
> 
>