On Thu, Mar 19, 2009 at 5:51 PM, Dirk Reiners <[email protected]> wrote: > > Hi All, > > Carsten Neumann wrote:
Thanks for the details Carsten. That is what I thought, but I wanted to make sure. >>> But, what happens if: >>> >>> - I have a primordial rendering thread and 2 background threads (P, >>> B1, B2) (each with their own default OpenSG settings) >>> - I create an object in P, store it with an MTRecPtr p_node, and share >>> that Ptr with B1 and B2 >> >> you need to sync the aspect of P with those of B1 and B2 before you can >> access the object from either thread. >> BTW this has not really changed from 1.x, except that in 1 the copies of >> P where already existing in the B1/B2 aspects, however they did *not* >> contain the correct values before the sync. > > Yup. The equivalent is accessing an uninitialized pointer: there is nothing to > point at, so the result is undefined. > >>> - When B1 or B2 accesses it, what data do they see? (assuming no >>> manually changelist syncing) >> >> if there has been no sync from the aspect of P to those of B1/B2 your >> application is likely to crash. The object you are trying to access does >> not exist before the sync. > > We could theoretically create a dummy object, but it would just mask what > amounts to a program error. It would be nicer not to crash but print an error > message or raise a signal (which is practically the same as a crash, but more > controlled) or throw an exception. I like the idea of detecting it and either ASSERTing with a helpful message about what the user did wrong and/or throwing an exception. >>> - What happens if in B1 I add a new node (b1_child) as a child of p_node? >> >> b1_child only exists in the aspect of B1 until you sync from aspect of >> B1 to aspect of P and aspect of B2. > > ... and you can't do that until you sync p_node into the aspect. > >>> Now option 2, what happens if I do this instead: >>> >>> - Same as above, but I explicitly set the aspect id for all threads to >>> be the same as the primordial thread >> >> you have three threads operate on the same aspect so becomes your own >> responsibility to coordinate their actions. > > Yup. > > That hints at a fundamental limitation of the OpenSG multi-threading model: it > only operates on a whole field basis. If you change the same field in multiple > aspects, the last one to sync wins. > > Which in general makes a lot of sense. For the children field we could think > about a different behavior, but I'm very weary about adding special cases for > specific fields. Maybe we could hide it in a special Group (MTCollectorGroup) > that does something magic. Not sure what, honestly, not sure how to handle an > object that is added in one thread and at the same time removed from another > thread. > > Stuff to think about... One idea I always wondered about was a form of cross syncing at known points for a set of threads. Let me explain: With a model like OpenSG's you invariably end up with a pipeline style architecture. One threads creates something, syncs it to the next that does something more, which then syncs to the next and so forth. It becomes much more difficult to sync things back the other way. That is great is works wonderfully. The concepts in OpenSG could support other models though. What I wonder about is supporting a blackboard style architecture pattern where multiple threads are working on their own objects but then a some coordination point they could all sync up at a barrier and cross sync all their changes. So for example given 3 threads A, B, and C: - Start working - Thread A renders based on the current graph - Thread B creates some new nodes, loads some files, computes some internal data - Thread C create some geometry and creates other nodes. - Connect - Threads are responsible for connecting up their created nodes to shared common nodes (MTRecPtr on a node) - Sync - All changes from all threads end up in all threads. - Everyone keeps going... The syncing could even be on-demand so it only happens when everyone is ready or something. This is effectively very similar to just having everyone use a single aspect and protect all access to the shared nodes using critical sections. May not be a good idea, just throwing it out there for smarter people to tell me how it should really work. :) -Allen > > Yours > > Dirk > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Opensg-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/opensg-users > ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
