[vtkusers] Thread-safety of New and Delete

[eewing]

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