[vtkusers] VTK in a multi-threaded program

Mon Mar 24 12:55:32 EDT 2014

Hi Richard,

Give VTK 6.1 a try. It was release in January and I believe it has all of
these changes in it. There may have been some minor fixes since then but
6.1 is definitely a good starting point. Note that there has been some API
changes in VTK 6 so you may have to update some of your code.

For reference, these changes were driven by this work:

http://www.vtk.org/Wiki/images/3/3b/VTK_SMP_Guide.pdf

Look at the Wiki for info on changes in 6.0:

http://www.vtk.org/Wiki/VTK

Here is a more detailed example of shallow copy:

global:

vtkSimpleCriticalSection Lock;
Lock.Init();

vtkDataSet* OutputCopy = 0;

thread 1:

filter->Update();
vtkDataSet* output = filter->GetOutput();

Lock.Lock()
OutputCopy = output->NewInstance();
OutputCopy->ShallowCopy(output);
Lock.Unlock();

thread 2:

vtkDataSet* renderedData;

Lock.Lock()
if (OutputCopy)
 {
 renderedData = OutputCopy->NewInstance();
 renderedData->ShallowCopy(OutputCopy);
 OutputCopy = 0;
 }
Lock.Unlock();

// Render renderedData here

Depending on the application, double shallow copy may be overkill but I
can't tell without knowing more. Also, I am guessing that you handle
messaging between threads in some way.

Best,
-berk

On Mon, Mar 24, 2014 at 12:37 PM, Richard Whitehead <
richard.whitehead at vivosight.com> wrote:

> Thanks Berk,
> I had no idea this work was in progress, it looks like you are going to
> solve the problem for me!!!   From the sound of it, you will not be
> introducing threads and triggers into VTK, that will still be an
> application domain issue, if I understand correctly?
> Please could you explain the couple of lines of code you included, I'm
> afraid I don't understand what the objects are or why you seem to refer to
> "output" twice in different ways?
> Are there any time-scales on when this work might reach a released build?
>  I'm working on a medical application and I am very reluctant to use an
> unstable build, but will do if I have to, the reward in this case would be
> significant.
> Huge thanks,
> Richard
>
>
> On 24 March 2014 15:14, 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
>>>>
>>>>
>>>
>>>
>>> --
>>> | 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20140324/e6e4a161/attachment-0001.html>