[vtkusers] VTK in a multi-threaded program

[David Gobbi]

Just as a quick note, right now vtkWeakPointer creation/destruction
is not thread safe.  The implementation uses a weak list that is not
locked while it is being modified.  Fortunately only a few VTK classes
use vtkWeakPointer, I think that this is the comprehensive list.  The
only one that is of any concern is the first one, because a
vtkPiecewiseFunction could be used by multiple threads.

So just a general warning: vtkWeakPointer should only be used
by rendering classes to refer to other rendering classes, since all
rendering classes must be in the same thread anyway.

vtkPiecewisePointHandleItem:  vtkWeakPointer<vtkPiecewiseFunction>
vtkWidgetRepresentation:  vtkWeakPointer<vtkRenderer>
vtkAxisFollower: vtkWeakPointer<vtkAxisActor>
vtkProp3DAxisFollower:  vtkWeakPointer<vtkAxisActor>
vtkProp3DAxisFollower:  vtkWeakPointer<vtkViewport>
vtkContextKeyEvent:  vtkWeakPointer<vtkRenderWindowInteractor>
vtkContextScene:  vtkWeakPointer<vtkContext2D>
vtkContextScene:  vtkWeakPointer<vtkRenderer>
vtkPainter:  vtkWeakPointer<vtkWindow>
vtkImageDataLIC2D:  vtkWeakPointer<vtkRenderWindow>
vtkImageDataLIC2DExtentTranslator:  vtkWeakPointer<vtkImageDataLIC2D>
vtkLineIntegralConvolution2D:  vtkWeakPointer<vtkRenderWindow>
vtkStructuredGridLIC2D:  vtkWeakPointer<vtkRenderWindow>
vtkDataTransferHelper:  vtkWeakPointer<vtkRenderWindow>
vtkFrameBufferObject:  vtkWeakPointer<vtkRenderWindow>
vtkFrameBufferObject2:  vtkWeakPointer<vtkRenderWindow>
vtkOpenGLExtensionManager:  vtkWeakPointer<vtkRenderWindow>
vtkOpenGLGlyph3DMapper:  vtkWeakPointer<vtkWindow>
vtkOpenGLTexture:  vtkWeakPointer<vtkRenderWindow>
vtkPixelBufferObject:  vtkWeakPointer<vtkRenderWindow>
vtkRenderbuffer:  vtkWeakPointer<vtkRenderWindow>
vtkShader2:  vtkWeakPointer<vtkRenderWindow>
vtkShaderProgram2:  vtkWeakPointer<vtkRenderWindow>
vtkTextureObject:  vtkWeakPointer<vtkRenderWindow>
vtkPSurfaceLICComposite:  vtkWeakPointer<vtkOpenGLRenderWindow>
vtkOpenGLHAVSVolumeMapper:  vtkWeakPointer<vtkRenderWindow>
vtkContextInteractorStyle:  vtkWeakPointer<vtkContextScene>

  David


On Mon, Mar 24, 2014 at 9:39 AM, Berk Geveci <berk.geveci at kitware.com> wrote:
> Correction:
>
> Render in one thread should _not_ cause filters that belong to another
> thread to execute.
>
> Best,
> -berk
>
>
>
> On Mon, Mar 24, 2014 at 11:14 AM, Berk Geveci <berk.geveci at kitware.com>
> wrote:
>>
>> Let me add my 2 cents.
>>
>> First of all, make sure that you are using the latest VTK from Git. It
>> makes reference count management thread safe. As long as the reference does
>> not go to 0 while another thread is using an object, it will be fine. Using
>> smart pointers will also be OK. Git VTK has bunch of other thread safety
>> improvements by the way.
>>
>> Second, when you hand data from the compute thread to the render thread, I
>> would use a shallow copy. Something like:
>>
>> copyToRender = output->NewInstance();
>> copyToRender->ShallowCopy(output);
>>
>> Make sure that this is protected by a mutex if the compute thread
>> eventually deletes "output". This would not be needed normally but there is
>> still some garbage collection left that may cause issues. This should make
>> it safe. It will be unnecessary in the future as we clean things more.
>>
>> Finally, never connect a pipeline across threads. Render should cause
>> filters that belong to another to execute.
>>
>> If you are still running into specific thread safety issue, try to trace
>> them with helgrind and please report them to this list or to me directly.
>>
>> Best,
>> -berk
>>
>>
>>
>>
>>
>> On Mon, Mar 24, 2014 at 11:00 AM, Aashish Chaudhary
>> <aashish.chaudhary at kitware.com> wrote:
>>>
>>> On Mon, Mar 24, 2014 at 10:53 AM, David Cole <dlrdave at aol.com> wrote:
>>>>
>>>> Hi Aashish,
>>>>
>>>> The blog post you pointed to was published in October 2012, and
>>>> referenced releasing the source code by the end of 2013. Was the source code
>>>> released? Is there a public repo for it?
>>>
>>>
>>> At the end of the blog, Rusty answered this question. Please have a look
>>> at it.
>>>>
>>>>
>>>> I find it hard to believe that the only thing you had to do was "a
>>>> vtkSmartPointer trick"...
>>>
>>>
>>> It was not just that but it was part of the core implementation.
>>>>
>>>>
>>>> If there is a way to run, for example, the vtkMarchingCubes filter on a
>>>> large volumetric dataset, with a pipeline that's in a background non-GUI
>>>> thread, it sure would be useful to have a snippet of example code that
>>>> proves it. Or any other long running vtkAlgorithm, for that matter.
>>>
>>>
>>> I don't remember what algorithms we ran but they were mostly image based
>>> or our own written in VTK.
>>>
>>> - Aashish
>>>>
>>>>
>>>>
>>>> Thanks,
>>>> David