Hi Carsten,

ok thank you for that explanation!

Maybe I am misusing OpenSG?!

I am having a model that keeps a root node of a scene. It also manipulates
that scene storing a lot of references to parts of the scene in the models
NodePtrs. It does so by the background thread simulating some movements and
changes to the scene, while the user is clicking controls in the views in
the gui thread. 

The controls are connected to the model and issue some properties to change
for example colors positions etc. so these are changed using gui controls.
At the same moment, I seem to be using the same nodeptrs to manipulate by
the gui thread by the simulation thread, also changing positions etc.

I think this leads to the crash as every nodeptr variable is actually used
in two aspects, right?

How would I have to set it up to have my model keep track of the nodeptrs
and manipulate them from both gui and simulation threads?

Do I need to implement the model using FieldContaines and the same itself to
avoid this problem? If I'd protect the models parts by mutices or the like,
the gui thread and the simulation thread would be serialized in their access
to the model, which only occurs when user interaction takes place. Still the
rendering might be unaffected as this is a timer based thing done by the gui
thread.

So far so good. There is one question left: My model keeps a NodePtr called
root. This root is being used by the window to go into a viewport for
rendering. But as mentioned above this root is also the base for changing
the scene during simulation. How would I make a copy of the NodePtr root and
make it stick to another aspect?

Class model
{
        NodePtr root;
Public:
...
        NodePtr getScene() { return root; };
}

Simulation thread: mutex protected access within aspect A0

        model->Mutex.lock();

        beginEditCP(..);
        TransformPtr
trafo(TransformPtr::dcast(model->getScene()->getChild(29)->getCore())->setMa
trix(...);
        endEditCP(..);

        model->Mutex.unlock();


Gui Thread:

        Mouse move: --> Mutex protected access within Aspect A0
                         --> mouse interaction will slow down simulation,
but don’t care at this moment
        model->Mutex.lock();
        
        mgr->hit(x,y);

        beginEditCP(..);
        TransformPtr
trafo(TransformPtr::dcast(model->getScene()->getChild(29)->getCore())->setMa
trix(...);
        endEditCP(..);
        
        model->Mutex.unlock();


GUI-Thread-Rendering:
        Rendering should run in parallel, therefore in aspect A1?!, 
        but how tell the window that now there is another aspect??

        mgr->setRoot(model->getScene());
        mgr->render();


Cheers Georg.

-----Ursprüngliche Nachricht-----
Von: Carsten Neumann [mailto:carsten_neum...@gmx.net] 
Gesendet: Freitag, 4. Dezember 2009 21:56
An: georg.wuen...@machineering.de
Cc: opensg-users@lists.sourceforge.net
Betreff: Threading/Aspects [WAS: OSG::Foreground resizing problem]

        Hello Georg,

Georg Wünsch wrote:
> Other topic: I am still on the way of trying to use OpenSG in a
> multithreaded environment. 
> 
>>From my understanding, the classes use a so called thread aspect. Does
that
> have something to do with any of the native thread ids or how would I
match
> them against each other to tell both open sg and the other apps parts
which
> thread they are on?

aspects and threads are two different things, you associate a thread 
with an aspect so that it knows on which copy of the scenegraph data it 
should work. Every aspect holds a copy of every container in the system 
(contents of fields are shared until a beginEditCP() requires an unshare 
to keep the overhead low).
When you create a thread you can associate it with an aspect (if you use 
some external library to create the thread you need to use the 
ExternalThread class to establish that association).

> I am having several models that have to be calculating some simulation in
> the background and manipulate open sg nodes and cores etc in one aspect, a
> background threads aspect.

right, those changes can be done in one aspect (say A1) as long as they 
don't touch the same containers concurrently. The rendering can keep 
running on a different aspect (A0) and is not affected by the changes 
until you apply the changes from the per thread (!) changelists to A0.

> In the mean time the gui thread might be trying to draw the scene in
another
> aspect as I understand it. The aspects btw are numbered as 1 and 2,
right?!

no, they are numbered 0,1,... In OpenSG 1.x their number is a compile 
time constant that defaults to 2.

> Every time I am switching the aspects something is crashing around a
> beginEditCP or endEditCP. What might I be doing wrong? Any Clue?

what do you mean by switching aspects? You should not be changing the 
aspect that a specific thread is associated with after it has done any 
work. Have you seen Doc/tutorial/progs/13multithreading2.cpp? The 
tutorial program is a highly simplified variant of something similar to 
what you are doing: Aspect 0 keeps rendering images while aspect 1 
updates the scene.

        Cheers,
                Carsten



------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Reply via email to