Where am I

24.2. Programming with Multiple Threads

Programming with multiple threads is much more complex than traditional programming in a single thread environment. It can be very difficult to avoid program crashs and “ deadlocks” due to threads using, or trying to use, the same resource at the same time. If you plan to create and use multiple threads directly in your application, we strongly recommend reading one or more of the books recommended in Section 24.5, “Programming Resources”.

One way to avoid the complexity of multithread programming is to simply take advantage of the use of multiple threads inside Open Inventor. Applications will generally benefit from these enhancements without requiring any modification to the application source code. For example, in core Open Inventor the SoExtTexture2 SoExtTexture2 SoExtTexture2 node (optionally) does the actual loading of texture image files asynchronously, using a separate thread to allow the initial scene to be displayed sooner. In MeshVizXLM, various extraction algorithms like mesh skin and grid plane slice (optionally) use multiple threads. In VolumeViz LDM multiple threads are used to load tiles of data in the background and the Data Access API provides a simple interface to asynchronous data loading. These are just a few examples, and additional internal use of multiple threads is added in every new release of Open Inventor.

It is also possible to avoid using multiple threads directly if your primary goal is to take advantage of multiple graphics pipes. The Open Inventor ScaleViz extension supports multi-pipe (multi-GPU) rendering using a configuration file that defines the display and pipe configuration, then automatically creates and manages multiple render threads (one for each pipe). Third party libraries such as CAVELib, MPSDK, and VRJuggler can also be used with Open Inventor. These libraries also read a configuration file and automatically manage the render threads. Please note that using these tools avoids the need to create and manage threads directly, but does not avoid the need to make custom nodes and application callbacks thread safe.