[vtkusers] Multi threading question

[Matthias Riechmann]

This might work - as long as there is no not-thread-safe code between in 
the procedures that are responsible for sending the StartEvent. And I'm 
not sure whether VTK likes events being stalled by mutexes, I'm not deep 
enough in VTK's event system. Are there any developers nearby? ;-)


Matthias




Clinton Stimpson schrieb:
> 
> How about locking/unlocking when you get the 
> vtkCommand::StartEvent/vtkCommand::EndEvent from the vtkRenderWindow?
> Then the locking is automatic no matter where Render() was called from.
> 
> Clint
> 
> Matthias Riechmann wrote:
>> I have a similar question: When triggering all rendering by yourself 
>> it is easy to protect VTK from concurrent access by using a mutex. But 
>> how can I do that when using a QVtkWidget? In this case the rendering 
>> might be triggered at any time from the GUI. Is there a way to do a 
>> synchronisation from a application programmer's view in this scenario?
>>
>>
>> Matthias
>>
>>
>>
>>
>> David E DeMarle schrieb:
>>> What you are doing is correct. VTK is not thread safe, so in general
>>> you have to protect against concurrent access manually as you have
>>> done.
>>>
>>> On Mon, Feb 23, 2009 at 10:51 PM, Anton Deguet <anton.deguet at jhu.edu> 
>>> wrote:
>>>> Hello,
>>>>
>>>> I have an application with one renderer and multiple actors.  Each 
>>>> actor (assembly) is controlled by a different thread and all use a 
>>>> single renderer (running in its own thread).  As a temporary 
>>>> solution, I use an application wide mutex lock/unlock for any access 
>>>> to VTK to avoid rendering while a thread is modifying the scene via 
>>>> its actor (threads can modify anything; position, size, visibility, 
>>>> opacity, texture, ... and other non atomic operations).  It somewhat 
>>>> works but I am afraid one programmer might forget to lock/unlock the 
>>>> scene before modifying its actors and this might be hard to 
>>>> debug/detect.  I am also slightly concerned by long waiting periods 
>>>> to lock the mutex as the application is growing.
>>>>
>>>> So, does VTK provide something better than what I am using, i.e. is 
>>>> there any build-in thread safety mechanism that one can use 
>>>> (multiple buffers, queued commands, ...) that would avoid locks.
>>>>
>>>> Thank you,
>>>>
>>>> Anton Deguet
>>>> _______________________________________________
>>>> 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
>>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> 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
>>   
> 
> 

-- 
Dipl.-Inform. Matthias Riechmann
Institut für Prozessrechentechnik, Automation und Robotik
Medizin-Gruppe
Universität Karlsruhe (TH)
Gebäude 40.28, Zimmer 103
Engler-Bunte-Ring 8
76131 Karlsruhe

Fon: +49 (721) 608-4049
Fax: +49 (721) 608-7141

Web: http://wwwipr.ira.uka.de/~richmann
-------------- next part --------------
A non-text attachment was scrubbed...
Name: riechmann.vcf
Type: text/x-vcard
Size: 483 bytes
Desc: not available
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20090226/8a8022be/attachment.vcf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3319 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20090226/8a8022be/attachment.bin>