Hi, On Mon, 2009-03-23 at 21:34 -0600, Allen Bierbaum wrote: > See below... > > On Mon, Mar 23, 2009 at 8:16 PM, Gerrit Voß <[email protected]> wrote: > > > > Hi, > > > > short comment, > >> 2) XxxPtr creation is not thread safe > >> > >> We think this one is killing us. To put it more concretely, imagine a > >> scenario like this... > >> > >> ---- P ------ > >> ChunkMaterialMTRecPtr mat = OSG::ChunkMaterial::create() > >> .... > >> SharedDataObject.setSharedMaterial(mat); > >> > >> ---- BG1 ---------- > >> GeomMTRecPtr geom = ... > >> ChunkMaterialMTRecPtr mat = SharedDataObject.getSharedMaterial(); > >> geom->setMaterial(mat) > >> > >> ---- BG2 ---------- > >> GeomMTRecPtr geom = ... > >> ChunkMaterialMTRecPtr mat = SharedDataObject.getSharedMaterial(); > >> geom->setMaterial(mat) > > > > here you modify the same object (mat) in more than one thread. > > Maybe this is the part we are missing. How does this modify the > Material object? Or do you mean the ref count on the field container > of the material object?
yes, the ref counter. > >> There is a race condition here on the reference counting. More > >> specifically, if multiple ChunkMaterialMTRecPtr's are created to the > >> same FC at close to the same time, the reference count can get out of > >> sync (we think). This can lead to dangling references and/or access > >> to destroyed objects. > >> > >> This may seem like a no-brainer issue, just don't do it. But it gets > >> more complex then that. For example this issue makes it so the simple > >> geom utilities in OpenSG are not thread safe because they call > >> getDefaultMaterial, which in turn creates RecPtrs that can get out of > >> sync. > >> > >> More generally, the problem is that RefPtrs can't be treated the same > >> as C++ primitive types. They can not be read from in parallel and > >> stay consistent. > > > > ?? why is reading from them a problem. If at all it should be writing > > to them. > > They can't be read from to create new copies of the same object > because in so doing the ref count can get out of sync. This is > because as you pointed out, there is a write (inc/dec) on the > underlying ref count and that is a race condition. This all makes > sense when thinking through the implementation, but when using them in > application code it just seems strange because what looks like a read > (ie. making a copy or passing by copy) on a refptr is actually a write > hazard. ok in that sense of read yes, but it is more the hidden write part of the lhs not the rhs which in my world is the read from element whereas the lhs is the written to element ;). That's why I was confused about your reading and writing. > I don't know how to solve this for sure, just wanted to point it out. > >> The thing that really tripped us up is that we are > >> used to using the boost shared_ptr implementation and it does allow > >> for this degreee of thread safety. They explain in much better then I > >> can: > >> http://www.boost.org/doc/libs/1_38_0/libs/smart_ptr/shared_ptr.htm#ThreadSafety > >> (copied here for easy access) > >> > > > > you compare the wrong thing, instrusive_ptr is closest to what we do. > > I will take a look. > > > It was somewhere on my list to look for atomic operations to make the > > ref counting safer. Looks like I have to push it up a little bit. Will > > have a look at it. > > boost/smart_ptr/details has an implementation that is cross platform > and is lock free on the primary OpenSG platforms. May be worth > reusing directly out of boost now that OpenSG uses boost. I'm looking at it and are about to change the refcounting to atomic operations. It's just compiling right now so I will know more soon ;) Hopefully you'll have a stable ref counter as you hit office tomorrow morning ;) kind regards, gerrit ------------------------------------------------------------------------------ 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
