[vtk-developers] Weak pointers and thread safety

[Moreland, Kenneth]

I'm skeptical that this code actually provides thread safety.  Your critical section is only applied within a weak pointer.  It is not applied within vtkObjectBase itself.  While the critical section is running some other thread could call unreference and delete the object after the weak pointer checks the reference but before the smart pointer increments the reference.

I think the only way you are going to get true thread safety is to put a critical section somewhere in the register/unregister calls.  However, that might slow down everything appreciably.

-Ken


On 10/11/10 10:43 PM, "Utkarsh Ayachit" <utkarsh.ayachit at kitware.com> wrote:

That sounds like a good idea. You have my vote.

Utkarsh

On Mon, Oct 11, 2010 at 10:35 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> Hi All,
>
> The VTK weak pointer implementation is not thread safe because it can
> be used just like a regular pointer, even though the object itself
> might be deleted by a separate thread at any time.
>
> By comparison, "safe" weak pointer like in boost and Qt cannot be used
> in place of ordinary pointers.  Instead, in order to use them their
> "GetPointer()"-like methods increment the reference count and then
> return a smart pointer, which is guaranteed to be valid until it goes
> out of scope:
>
> vtkSmartPointer<SomeClass> smartPtr = weakPtr.GetPointer();
> if (smartPtr.GetPointer() != 0)
>  {
>  // do something with smartPtr
>  }
> // reference count decremented when smartPtr goes out of scope
>
> Because VTK's vtkWeakPointer::GetPointer() does not return a smart
> pointer or do any thread locking, thread-safe use of vtkWeakPointer
> requires the following:
>
> vtkSimpleCriticalSection critSec;
> critSec.Lock();
> vtkSmartPointer<SomeClass> smartPtr = weakPtr.GetPointer();
> critSec.Unlock();
> if (smartPtr.GetPointer() != 0)
>  {
>  // do something with smartPtr
>  }
>
> If weakPtr.GetPointer() was changed to return a smart pointer, then it
> could do the locking internally.  This change would be mostly, but not
> completely, backwards compatible.  What do people think?
>
>  David
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.vtk.org/mailman/listinfo/vtk-developers





   ****      Kenneth Moreland
    ***      Sandia National Laboratories
***********
*** *** ***  email: kmorel at sandia.gov
**  ***  **  phone: (505) 844-8919
    ***      web:   http://www.cs.unm.edu/~kmorel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20101012/8b37e06d/attachment.html>