[Insight-developers] Re: LightObject race condition fix

[Simon Warfield]

Steve M. Robbins wrote:
> Hi Simon,
>
> I made the same objection originally, but I later realized it is a
> faulty design.
>
> http://www.itk.org/mailman/private/insight-developers/2007-July/009239.html
>
>
> On Mon, Aug 06, 2007 at 12:29:58PM -0400, Simon Warfield wrote:
>
>   
>> So imagine the following sequence of events:
>> Object A in thread 1 calls UnRegister() on a LightObject L shared across 
>> threads.
>>
>> L obtains a lock, and decrements the temporary reference count to be equal 
>> to zero, and releases the lock.
>>
>> Object B in thread 2 , unaware that Object A has asked L to destroy itself, 
>> calls Register().
>>     
>
> The error is this: Object B must have a reference for L before calling
> any method of L, e.g. Register().  Then there is no problem: Object A
> is not decrementing L's reference count to 0.
>
> Cheers,
> -Steve
>   
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.
It doesn't look to me like the current design is doing that.

  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).

-- 
Simon