[vtkusers] VTK in a multi-threaded program

Richard Whitehead richard.whitehead at vivosight.com
Mon Mar 24 12:48:28 EDT 2014


Berk,
I don't believe that what you're saying is true, at least with VTK 6.0
which I'm using.   As an example, I was saving data using vtkTifffWriter in
a background thread; the writer was local to the save method, created with
a vtkSmartPointer.  What happened was that at the end of the method, the
vtkSmartPointer's reference count had got messed up (I would have expected
it to be 1) and the garbage collector tried to clean up something that was
full of 0xfeeefeee values and a GPF resulted.  Using my own thread-safe
smart pointer did not help, because of the temporaries being created
internally; but by wrapping a smart-pointer it did allow me to print out
the reference count every time a method was called, and I could see it
jumping around, not incrementing and decrementing by 1 as I expected.
My solution in the above case was to take VTK out of the writing threads,
crash solved but hair colour saturation reduced.
Many thanks,
Richard



On 24 March 2014 16:37, Berk Geveci <berk.geveci at kitware.com> wrote:

> To clarify one thing about garbage collection:
>
> As long as 2 threads are not doing garbage collection calls to the same
> objects, garbage collection is thread safe. This is only an issue if you
> update the reference of objects that refer to each other in some way from
> multiple threads. The simplest way of getting rid of this is to not share
> data objects but use shallow copy to share contents of data objects
> (arrays). Also, as of VTK 6, data objects are not part of the pipeline's
> reference loop so it is thread safe to share data objects from multiple
> threads. Having said that, data objects have bunch of API that is not
> thread safe so reading data objects from multiple threads is discourage
> unless you carefully design the code.
>
> Best,
> -berk
>
>
>
> On Mon, Mar 24, 2014 at 12:26 PM, Richard Whitehead <
> richard.whitehead at vivosight.com> wrote:
>
>> Seb,
>> Many thanks for the reply.  I don't think that what you suggest can
>> necessarily be safe, because Update might create temporary objects and that
>> involves the singleton garbage collector.
>>
>> The correct solution is for the garbage collector to be thread-safe. This
>> would only involve some mutex locking, but I don't feel confident to
>> attempt it, even if I had time (I'm now under a lot of time pressure).
>> Many thanks,
>>
>> Richard
>>
>>
>> On 24 March 2014 14:56, Sebastien Jourdain <
>> sebastien.jourdain at kitware.com> wrote:
>>
>>> Another approach could be that the creation and the linkage with the UI
>>> is going through the single UI thread, but you rely on another thread to
>>> execute the actual pipeline by calling Update() on the mapper. Although, do
>>> not connect that pipeline yet to the render window until that working
>>> thread is done.
>>>
>>> Just my 2 cents,
>>>
>>> Seb
>>>
>>>
>>>
>>> On Mon, Mar 24, 2014 at 8:32 AM, Aashish Chaudhary <
>>> aashish.chaudhary at kitware.com> wrote:
>>>
>>>> Hi Richard,
>>>>
>>>>  On Mon, Mar 24, 2014 at 10:25 AM, Richard Whitehead <
>>>> richard.whitehead at vivosight.com> wrote:
>>>>
>>>>> David,
>>>>> Unfortunately I am now in a really bad place.  I have some long-winded
>>>>> calculations to do and then visualise, which I want to do in a background
>>>>> thread.  This is for a commercial application and hanging the GUI is
>>>>> completely unacceptable.  I have now invested several man-months into VTK
>>>>> and I have to decide whether to drop it.  I think the only sensible thing I
>>>>> can do is to get rid of VTK from my calculations and only use it for
>>>>> visualisation.
>>>>>
>>>>
>>>> FYI, we have successfully used VTK in a multi-threaded environment for
>>>> our VisGUI application framework (
>>>> http://www.kitware.com/source/home/post/84) specifically dealing with
>>>> computations. Rendering was done single threaded though. The trick involved
>>>> writing our own thread safe version of vtkSmartPointer (I believe you are
>>>> doing something similar).
>>>>
>>>> - Aashish
>>>>
>>>>
>>>>
>>>>>  Many thanks,
>>>>> Richard
>>>>>
>>>>>
>>>>>
>>>>> On 24 March 2014 12:29, David Cole <dlrdave at aol.com> wrote:
>>>>>
>>>>>> You are definitely not going crazy. The really, really rather foul
>>>>>> thing, that frustrates me all the time, is when I must do some VTK
>>>>>> operation which takes significant time (on the order of seconds or minutes,
>>>>>> rather than the typical fraction of a second) ... and then it makes the GUI
>>>>>> completely unresponsive until the operation is done.
>>>>>>
>>>>>> I spend rather a lot of my time making sure that everything I do
>>>>>> that's VTK-based is at interactive speeds as much as possible to absolutely
>>>>>> minimize the user pain associated with this.
>>>>>>
>>>>>> Pushing long operations completely into a separate non-GUI thread
>>>>>> would be absolutely fantastic. I look forward to the day when such a thing
>>>>>> becomes possible.
>>>>>>
>>>>>>
>>>>>> :-)
>>>>>> D
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Richard Whitehead *-* Senior Imaging Engineer
>>>>>
>>>>> *Michelson Diagnostics Ltd*
>>>>>
>>>>> *M:* +44 (0)7905 955276   *T:* +44 (0)20 8308 1695
>>>>>
>>>>> *E: *richard.whitehead at vivosight.com   *W:* www.vivosight.com
>>>>>
>>>>>
>>>>> <http://www.vivosight.com/>
>>>>>
>>>>>
>>>>> Michelson Diagnostics Ltd, 1 Grays Farm Production Village, Grays Farm
>>>>> Road, Orpington, Kent  BR5 3BD, UK
>>>>>
>>>>> Registered Office: 3 Shearwater, Maidstone, ME16 0DW.     Registered
>>>>> in England No. 5732681
>>>>>
>>>>> _______________________________________________
>>>>> Powered by www.kitware.com
>>>>>
>>>>> Visit other Kitware open-source projects at
>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>
>>>>> Please keep messages on-topic and check the VTK FAQ at:
>>>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>>>
>>>>> Follow this link to subscribe/unsubscribe:
>>>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> | Aashish Chaudhary
>>>> | R&D Engineer
>>>> | Kitware Inc.
>>>> | www.kitware.com
>>>>
>>>> _______________________________________________
>>>> Powered by www.kitware.com
>>>>
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Please keep messages on-topic and check the VTK FAQ at:
>>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>>>
>>>>
>>>
>>
>>
>> --
>>
>> Richard Whitehead *-* Senior Imaging Engineer
>>
>> *Michelson Diagnostics Ltd*
>>
>> *M:* +44 (0)7905 955276   *T:* +44 (0)20 8308 1695
>>
>> *E: *richard.whitehead at vivosight.com   *W:* www.vivosight.com
>>
>>
>> <http://www.vivosight.com/>
>>
>>
>> Michelson Diagnostics Ltd, 1 Grays Farm Production Village, Grays Farm
>> Road, Orpington, Kent  BR5 3BD, UK
>>
>> Registered Office: 3 Shearwater, Maidstone, ME16 0DW.     Registered in
>> England No. 5732681
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the VTK FAQ at:
>> http://www.vtk.org/Wiki/VTK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.vtk.org/mailman/listinfo/vtkusers
>>
>>
>


-- 

Richard Whitehead *-* Senior Imaging Engineer

*Michelson Diagnostics Ltd*

*M:* +44 (0)7905 955276   *T:* +44 (0)20 8308 1695

*E: *richard.whitehead at vivosight.com   *W:* www.vivosight.com


<http://www.vivosight.com/>


Michelson Diagnostics Ltd, 1 Grays Farm Production Village, Grays Farm
Road, Orpington, Kent  BR5 3BD, UK

Registered Office: 3 Shearwater, Maidstone, ME16 0DW.     Registered in
England No. 5732681
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20140324/b743dd90/attachment.html>


More information about the vtkusers mailing list