On Mon, Mar 23, 2009 at 10:50 PM, Gerrit Voß <[email protected]> wrote: > > 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 ;)
Ah, the benefits of open source. There is always someone working on OpenSG at any time of day. :) Thanks. I will give it a try. -Allen ------------------------------------------------------------------------------ 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
