[Insight-developers] Re: LightObject race condition fix

[Steve M. Robbins]

On Mon, Aug 06, 2007 at 05:03:45PM -0400, Simon Warfield wrote:

> I think the thread-safeness of these operations should be enforced or at 
> least encouraged by some kind of API that makes it easy to do the right 
> thing.

That's surely desirable, though I'm not smart or imaginative enough to
see how an API could *enforce* safety: it's easy to call UnRegister()
more times than Register(), even within a single thread.


>  I agree with you, that if all objects are required to call Register() 
> before manipulating the light object, then the reference count can only 
> drop to zero if they have all called Unregister().  I don't think the API 
> actually enforces that usage pattern (look at SetReferenceCount() for 
> example).

In my estimation, SetReferenceCount() is an abomination that should
simply be removed.  I can't imagine how it might be useful.

A quick grep of the ITK sources shows it is used just once: the
FEM_CLASS macro of Code/Numerics/FEM/itkFEMMacro.h:

    /** Create a new object from the existing one */  \
    virtual Baseclass::Pointer Clone() const \
      { Pointer o=new Self(*this);           \
        o->SetReferenceCount(1);             \
        return o; }                          \

I think this call could be removed since any copy constructor of a
LightObject subclass will necessarily create a new object with
reference count of 1.

In addition, there are a few uses of SetReferenceCount() in
InsightApplications, but these are all easily replaceable by a call to
Register().

Developers: what is the use-case for SetReferenceCount()?

-Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.itk.org/mailman/private/insight-developers/attachments/20070807/8ad109c5/attachment.pgp