[vtkusers] Thread-safety of New and Delete

[David Gobbi]

What do you mean by "filter-by-filter" basis? Each filter is in its own
thread?

If you need asynchronous IO, then a typical approach is to start the thread
that does the IO, and then poll that thread until the IO is complete.  When
the IO is complete, feed the data into your pipeline.  This solution is not
specific to VTK in any way, of course.  It's just a general approach to
asynchronous IO that works as well with VTK as with anything else.  You can
also have the thread read the data piece-by-piece, which would be a bit
more complicated.

It also works for asynchronous processing.  For long processing tasks, we
start a QThread that does the processing and emits a signal when the
processing is done.  When our app receives the signal, it knows it's safe
to use the result.  In this case Qt is doing the polling for us as part of
its mainloop.

 - David

On Wed, Jan 13, 2016 at 3:39 PM, eewing <eewing at cs.uoregon.edu> wrote:

> Hi David,
>
> Thanks for the quick response. That actually answers my issue. I'm working
> on threaded I/O as part of a large pipeline, described by your first
> example. The pipeline is executed in parts by threads, but on a
> filter-by-filter basis, with no way to lock data to a specific thread.
>
> What would your recommendation be to mitigate the issue? I've seen a
> suggestion to create a "I'm accessing VTK" mutex for whenever you are
> accessing VTK, but I'd like to avoid that if possible.
>
> -Elliott
>
>
>
> On 2016-01-13 14:20, David Gobbi wrote:
>
>> Hi Elliott,
>>
>> Can you describe your issue in more detail?  The VTK New and Delete
>> calls should be thread safe. The two caveats for VTK and threads are:
>>
>> 1) All classes that do rendering should be in the same thread (all
>> mappers, actors, renderers, etc), and there shouldn't be multiple
>> threads hitting the same rendering context.
>>
>> 2) Movement of data between threads must be locked or otherwise done
>> in a thread-safe manner.
>>
>> You would not, for example, create a single pipeline that is accessed
>> from multiple threads.  Each thread would have its own pipeline
>> segment, with locks to synchronize a copy (or move) of data from the
>> output of one segment to the input of another segment.
>>
>>  - David
>>
>> On Wed, Jan 13, 2016 at 2:27 PM, eewing <eewing at cs.uoregon.edu> wrote:
>>
>> Hello,
>>>
>>> I'm running into some issues with VTK in a threaded environment,
>>> and it seems that the source of the problem is in VTK's New and
>>> Delete calls. So, are the New and Delete calls thread-safe? If not,
>>> is there a recommended alternative that I can use inside my threads?
>>>
>>> Best,
>>> -Elliott Ewing
>>> University of Oregon
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160113/5320f668/attachment.html>