Hey,
Thanks a lot. I guess I'll revert the change, and see if I can find another
way to lose the warning.
Regards,
Blagoja Stojkoski
On Fri, Sep 19, 2014 at 9:32 AM, Carsten Neumann <
carsten.p.neum...@gmail.com> wrote:
> Hello,
>
> On 09/18/2014 04:42 PM, Благоја Стојкоски wrote:
> > Now, the scenario that I have is, I have 4 threads whose changes get
> > merged like so:
> >
> >
> OSG::Thread::getCurrentChangeList()->merge(*my_threads[i]->getChangeList());
> >
> > This is done in a for cycle that goes through all the threads.
> > my_threads is an array of OSG::ThreadRefPtr
> >
> > After this the changes in the threads get cleared with this call:
> >
> > my_threads[i]->getChangeList()->clear();
> >
> > This is where the warning message appears. It gets generated in the
> > FieldContainer.cpp file in line 322
> > (
> http://sourceforge.net/p/opensg/code/ci/master/tree/Source/Base/FieldContainer/Base/OSGFieldContainer.cpp#l322
> )
> >
> > I managed to "fix" this by changing the clearing of the ChangeList to:
> >
> > my_threads[i]->getCurrentChangeList()->clear();
> >
> > However, I cannot find what is the difference between getChangeList and
> > getCurrentChangeList, so I can not be sure if what I did is correct.
> > When testing the program with this change in place, I can not spot
> > anything wrong, but I just want to be sure.
>
> I doubt this does what you want it to do: Thread::getCurrentChangeList()
> is a static member function that returns the ChangeList (CL) of the
> thread executing the code, while getChangeList is a (non-static) member
> function that returns the CL of the thread object it is called on. So
> after the change you are only clearing the current threads CL, not those
> you've merged from.
>
> The message warns that multiple threads are operating on the same aspect
> (essentially copies of a FieldContainer (FC) that are associated with
> threads) and modify the same FC. This can be problematic since changes
> are recorded in a per-thread CL, but each aspect copy of a FC only has
> one pointer to a CL entry. If, for example, thread A is the first to
> modify a FC f then f._pContainerChanges is set up to point into the CL
> of A. If later a thread B on the same aspect copy also modifies f the
> change should be recorded in the CL of B, but since f._pContainerChanges
> already exists that record is just augmented to also store the latter
> change.
> Whether that is a problem in practice is hard to say in general.
>
> > That's why I decided to ask you guys. Also I would like to ask you if
> > you could point me to some other sources of documentation or tutorials
> > for the latest OpenSG, apart from the wiki on http://www.opensg.org/ and
> > the documentation on http://opensg.fraunhofer.sg?
>
> I don't think we have any.
>
> Cheers,
> Carsten
>
>
> ------------------------------------------------------------------------------
> Slashdot TV. Video for Nerds. Stuff that Matters.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> _______________________________________________
> Opensg-users mailing list
> Opensg-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/opensg-users
>
------------------------------------------------------------------------------
Slashdot TV. Video for Nerds. Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
