[Insight-developers] LightObject race condition fix

[Steve M. Robbins]

On Tue, Jul 10, 2007 at 11:48:54PM +0200, Gaëtan Lehmann wrote:

> About the Steve's example, a light object should never get a Register() 
> call when m_ReferenceCount is 0, because at that point, the object is, or 
> will be, deleted, so it is likely to show a bug in the program. The 

You're right, of course.  In my defense: the light object may have
m_ReferenceCount = 1 at the start of Register() but simply lose the
race and get blocked waiting for the lock while the other thread does
Unregister().

As you suggest, however, that's a symptom of faulty design.  The rule
should be: you may only call Register() -- indeed, *any* method -- if
your thread already has a reference on the object.


> behavior with the patch in that example does not seem worse than without 
> the patch - and it doesn't seem better though. In that case, I think it's 
> up to the user to keep a smart pointer in a safe place so it can be safely 
> referenced in a thread.

Agreed.

Incidentally, I was reading through an article by Herb Sutter that
makes the point that "calling into any unknown code while holding a
lock is a recipe for deadlock" [http://www.ddj.com/dept/cpp/184401930],
which is one reason for not putting "delete this" in the critical
section.

Cheers,
-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/20070711/a2373377/attachment.pgp