Re: multithreading issues and the scene graph

New Message Reply Date view Thread view Subject view Author view

Gregory Schultz (gschultz++at++mitre.org)
Tue, 02 Nov 1999 16:05:47 -0500


You might also want to consider using pfDataPool and APP stage
traversals to transform the DCS nodes of the DynamicModel objects.
pfDataPools are similar
to shared memory and have lock and unlock mechanisms for elements in the
pfDataPool.

Hope this helps!

Greg Schultz

Anthony Bavuso wrote:
>
> I have a questions regarding multithreading, mutual exclusion, and the scene
> graph.
>
> I am designing a prototype flight simulator. I have created a class to
> represent visible dynamic models (models that move) in the simulation that
> run in their own thread of execution (using pthreads). This class called
> DynamicModel has a pointer to a pfDCS and a child pfNode for the geometry
> which are both children of the root scene graph node.
>
> The DynamicModel model objects updates the pfDCS node to alter model
> position in its own thread and hence asynchronously to performer traversing
> the scene graph.
>
> There are obvious problems that this could cause. For example the
> DynamicModel may be writing to the pfDCS node while performer is trying to
> read it. Problems solved by using some kind of semaphore, mutex, lock, etc.
>
> My question is, Does performer have built-in to the pfDCS class and-or its
> parent class, come kind of locking mechanism to prevent these problems? Can
> you point me to where I could find documentation on this issue?
>
> Also if the locking capability is not built in, would it be a good idea to
> derive a new class from pfDCS that incorporates this functionality? Has
> anyone done this successfully?
>
> Thanks.
>
> -----------------------------------------------------------------------
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Tue Nov 02 1999 - 12:59:28 PST

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.