Re: [vistavrtoolkit-general] Vista threading

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi,

Thank you very much for your comprehensive answers! Especially your statements concerning the synchronization between OpenSG and ViSTA are very clarifying.

I tried the Acceptor-class for accepting new connections and it works great (under both OS), thanks for the pointer.

For the dynamical change of the scene graph I decided to maintain my own (synchronized) list of change-sets between the parsing thread (XMLs are up to 0,5 MB, direct parsing with render-thread is not as smooth as I want it). Every update the (parsed and preprocessed) changes are then applied to the scene graph by the render-thread. This is (hopefully) sufficient for my purpose and allows me to use the Vista-API (and is simpler/faster for me to implement then starting to use OpenSG).

MSVC 10:
I really don't know how, but Rob...@dl... managed to build it (win7_32). =)

Best regards,

Gero

-----Ursprüngliche Nachricht-----
Von: Ingo Assenmacher [mailto:iar...@ya...] 
Gesendet: Mittwoch, 17. August 2011 21:27
An: Beer, Thomas; Leinemann, Gero; vis...@li...
Betreff: Re: [vistavrtoolkit-general] Vista threading

Some things I forgot to mention:

* it suffices to register a thread that is modifying a field container in a node, there is an opensg api for that, This means that it is not mandatory, as you might have read in my last mail, to create a thread based on opensg threads to really perform the modification. I do not have the API call in memory right now and can not access code examples, but it is quite visible in the respective opensg source. You could call that method for example in a VistaThread::Post() call or in the constructor of your thread, if you chose to subclass (if I remember correctly, it is something like "register<something>", maybe Thomas has more precise hints here).

* when playing around with the field containers, you should (to be more precise: you must) avoid using the Vista layer of the scene graph (Dominik already suggested to lock the whole vistasg during any modification). This code layer is/was not designed to be thread safe. It should be possible, however, to use most of the code in the bridges directly (there is not much state in there, so only avoid methods that change bridge state). In a nutshell: if you want to use this advanced feature: get all pointers to implementation layer objects in non-parallel code and work on the opensg structures directly.

* during syncronization, for example as done in the code that Thomas sent, you have to have access to all threads that have write access to any field container. Stop them (e.g., by using a thread barrier), sync their change lists and continue with the processing. If you do so during the vista event dispatching, you can be sure that there is no thread that is traversing the scene graph at this time.

Hope it helps,

Ingo.

----- Ursprüngliche Message -----
Von: "Beer, Thomas" <be...@vr...>
An: "Ger...@dl..." <Ger...@dl...>; "vis...@li..." <vis...@li...>
Cc: 
Gesendet: 10:35 Mittwoch, 17.August 2011
Betreff: Re: [vistavrtoolkit-general] Vista threading

Hi Gero,

There is an example on multithreading hidden in the OpenSG 1.8 sources in Doc/tutorial/progs/13multithreading_2.cpp - I attached the file.

OpenSG can store a ChangeList per thread aspect (there are exactly 2 aspects in a an OpenSG built with the default configuration) where all changes to the FieldContainers are noted. This has to be enabled explicitly, see the attached code. At specific synchronization points in the application (e.g. in a POSTLOOP Event as Ingo suggested) those lists are used to sync the thread aspects.

Regards,
Thomas

--

Thomas Beer, M.Sc.

Virtual Reality Group, RWTH Aachen University Institute for Scientific Computing Center for Computing and Communication Seffenter Weg 23, 52074 Aachen (Germany)

Phone : +49 241 80 24378
Email : be...@vr...
URL   : http://www.vr.rwth-aachen.de

> -----Original Message-----
> From: Ingo Assenmacher [mailto:iar...@ya...]
> Sent: Tuesday, August 16, 2011 10:35 PM
> To: Ger...@dl...; 
> vis...@li...
> Subject: Re: [vistavrtoolkit-general] Vista threading
>
> Hello Gero,
>
>
>
> > I'm currently using the vista threading classes (VistaMutex/Lock,
> VistaThread/Loop, VistaSemaphore, VistaThreadCondition) to implement a 
> simple application that receives a XML string, parses it and then adds 
> different nodes to the scene (at runtime).
>
> > While everything works fine under Win7_x64 with VS10, I got several
> issues/random errors/different behavior under Linux (SLED 11/gcc). To 
> be honest, I don't really know _what_ I need to synchronize (every 
> change to the scene graph, only certain calls or nothing?), and maybe 
> I'm using the Vista-API wrong (and the Win implementation is more 
> tolerant then Posix...?).
>
>
>
> OpenSG threading needs threads to be registered with the OpenSG layer, 
> otherwise, any resulting state of the scene graph is undetermined. On 
> every write to the scene graph data structures, each container checks 
> the current TID to select the correct aspect of the node-containers 
> (that is the back- buffer of the node).
> There is currently no support in the kernel to help you very much 
> here, but you can meld your own.
>
> 1) Each thread class in Vista is created by an "implementation" 
> (regard this as a factory for any platform dependent thread). By 
> default, each instance of a thread receives a NULL pointer to select 
> one of the default. You can create an OpenSG implementation and create 
> a thread using opensg threads for all threads that manipulate the 
> scene graph (yes, this can be mixed with "normal"
> threads in other places. Using the opensg api for threads lets you 
> select the proper aspect ID.
>
> 2) you have to select a place where to swap changes from the change 
> lists from any back-buffer to the front buffers of the scene graph. 
> This has to be done while the rendering is not taking place,  e.g. the 
> scene graph is not traversed. Maybe do this in a POSTLOOP event. For 
> how to do that, please refer to the OpenSG 1.8 documentation.
>
>
> I remember there was already a diploma thesis trying this out (it was not 
> hte
> major focus, but one of the working packages). Maybe Dominik can find some
> code snippets. If you need an example of how to create the OpenSG
> implementation (I doubt that... its simple), there was code in there, I am
> sure.
>
> <yourmail>
>
> ##### 1. Adding nodes to the SG
>
> // ----------------------------------------------------------
>
> This basically works (under Linux as well as Windows), but have the feeling
> that there must be a more elegant way to do this...? Or maybe the error is
> just my fault? As far as I understood OpenSG should handle synchronization, 
> or
> not?
> </yourmail>
> No, OpenSG does not handle synchronization for you. By design (version 1.8
> this is, not sure about 2.x) all you get is backbuffers (empty) on every 
> node.
> You have to chose the place of when and where to sync your state.
>
>
> <yourmail>
> ##### 2. Shutting down a VistaTCPServer
>
> I subclassed VistaTCPServer and VistaThreadLoop to handle incoming
> connections. When closing the program, the "Stop(bool)" method is called:
>
> // ----------------------------------------------------------
>
> void Server::Stop(bool wait)
> {
>     stop = true;
>     StopAccept();    // Should cause the listening thread to return from the
> socket
>
>     if (wait)
>     {
>         StopGently(true);            // Stopping thread hangs HERE
>     }
> }
>
> bool Server::LoopBody()
> {
>     if (stop) {
>         return true;
>     }
>
>     VistaTCPSocket *client = GetNextClient();    // Listening thread stays
> HERE...
>     if (client != NULL)
>     {
>         ClientConnection* cc = new ClientConnection(client, queuePtr);
>         synchronized (clientMutex) {
>             clientConnections->push_back(cc);
>         }
>     }
>
>     return stop;
> }
>
> // ----------------------------------------------------------
>
> Under SLED 11, this leads to a deadlock on shutdown: The main-thread hangs 
> in
> "StopGently(true)", while the VistaTCPServer won't return from
> "GetNextClient()" (internally: VistaTCPServerSocket::Accept). Windows works
> fine, though!??
>
> </yourmail>
>
> I would have to check the implementation of StopAccept() on unix systems, 
> but
> passing "true" to StopGently() means that any calling thread waits for a
> handshake with the loop thread. If StopAccept() does not break the wait
> condition on a unix system, then there will be no handshake, hence it will
> wait. I would not really say it is a deadlock, as I suspect that the
> GetNextClient() will return once there is a new connect and a handshake 
> could
> pass, no?. I see a check of "if(stop)...". I am not sure of where this is
> coming from, but it look suspicios, as if you are using abool to control a
> thread stop state. This is generally (not only for the Vista implementation)
> not recommended, as you never know what a compiler does with this statement.
> Some mark "stop" as volatile to avoid optimization, but generally idioms 
> like
> this lead to race conditions. Besides that... you implement "LoopBody()", so
> you could use the implementation of the ThreadLoop for state
>  control.
> In case you have more questions, feel free to ask. And if I missed something
> about the OpenSG thread model, all OpenSG gurus on the list can fire up now.
>
> Best regards,
>
> Ingo.
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> vistavrtoolkit-general mailing list
> vis...@li...
> https://lists.sourceforge.net/lists/listinfo/vistavrtoolkit-general

------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________
vistavrtoolkit-general mailing list
vis...@li...
https://lists.sourceforge.net/lists/listinfo/vistavrtoolkit-general