[Insight-developers] Re: LightObject race condition fix

[Dan Mueller]

On 13/08/07, Steve M. Robbins <steve at sumost.ca> wrote:
> On Wed, Aug 08, 2007 at 06:09:43AM +1000, Dan Mueller wrote:
> > On 07/08/07, Steve M. Robbins <steve at sumost.ca> wrote:
> > > Developers: what is the use-case for SetReferenceCount()?
> >
> > I know I use SetReferenceCount(): I have cases (to do with wrapping
> > for .NET) where I do not know how many calls to Register() have gone
> > before, but I do know when the object can be released. At that point I
> > call SetReferenceCount(0) to force the pointer to be freed.
>
> OK, I'll bite: how do you know that the object can be released?
>
> I don't know anything about .NET and wrapping itk for it.  However, I
> did once look into the java wrapping of vtk.  In that case, there is a
> java proxy object for each C++ object and the proxy holds exactly one
> reference to the C++ instance.  When the proxy is finalized, the
> reference is decremented.  Can't this approach be used in ITK/.NET?

I use a similar approach to the vtk/java approach you describe: a
managed wrapper object (read 'proxy object') keeps a reference to the
underlying C++ object, and when the wrapper object is finalized the
native reference can be freed.

As I mentioned previously, due to a C++/CLI limitation, the wrapper
object can only keep a native pointer to any ITK object, not a
SmartPointer. Therefore, I have found on subsequent calls to the
wrapper methods the SmartPointer thinks it is going out of scope and
frees itself. To combat this, I call Register() on the native ITK
pointer within every wrapper method to ensure the wrapped native
object is kept alive. SetReferenceCount(0) seemed the safest way to
ensure the native object is released when the wrapper is finalized.

Thinking about this further, it may well be that the reference count
_is_ kept at 1 and UnRegister() would work --- it's something I will
need to investigate further when time permits. Anyhow, for the moment
I use SetReferenceCount(0) as a safe gaurd...

Cheers, Dan