Hi, On Thu, 2009-03-26 at 17:21 -0500, Carsten Neumann wrote: > Hi Gerrit, all, > > Gerrit Voß wrote: > >> relatively, the problem is that the only consistent thing they export is > >> the blob (sp_counted_base), not the atomic operations we need, so we > >> might take some inspiration from there but I guess we have to do the > >> two required functions (atomicInc, atomicExAndAdd) by ourselves. But > >> we can fallback to boost where we can. > >> > > > > which we do now, could you try and let us know if the change to atomic > > counting makes any difference for your app ? > > unfortunately this broke one of the unit tests (I'm about to have them > back in working order), > Source/System/NodeCores/Groups/Light/OSGLightReferenceCountTest.cpp. > The problem is that the modification of the ref counts moved with > respect to the resolveLinks() call (which can affect the the ref count > of the current container through weak pointers from elsewhere in the tree). > > The tree for the test looks like this: > > // np0[gp0] <------------+ > // +----------+ | > // np1[gp1] np2[gp2] | beacon > // | | > // np3[lp0]--------------+ > > and there is only one rec pointer to np0 that then is set to NULL to get > rid of the whole tree.
> Before, np0 had a ref count of 1 when np3 performed its resolveLinks() > and subsequently called subWeakReference() on np0. Therefore the if > inside subWeakReference never applied and the container was not deleted > from subWeakReference, but instead later when control returned to the > subReferenceRecorded on np0. > First I thought we could fix this by just getting rid of the > (superfluous anyways) resolveLinks() inside subWeakReference(). But, > there is still the problem of the np0 d'tor running early (while > children field of np0 is in the process of being emptied). Ah ok, I change the order back so that that one works again. > Thinking about this some more Dirk and I found three problematic scenarios: > > 1) the above situation with a beacon pointing "back" to an object that > already has a sub[Weak]Reference() running, > 2) an object that only has a weak pointer to it (e.g. it is held in a > cache). > 3) two threads one giving up a reference to an object the other one > giving up a weak reference (this case currently still has a race I think). > > We noticed that all three problems can be solved if weak references do > not keep the object "alive". For 1) the d'tor will not run early when > the weak reference from lp0 goes away, for 2) the object must have been > cleaned up when the last strong reference went away and for 3) we only > need to ensure that the threads atomically modify the ref counts and > base their actions on the previous value. > The idea to solve this is to have the weak pointers point at the > AspectStore (and use its ref count to count weak refs as well). IIRC we had this discussion before but I don't exactly recall why we choose the current form. > Then we > can destroy the FieldContainer objects when the last strong reference > goes away, but the weak pointer can still detect this (the aspect store > will have a NULL pointer for the current aspect). A side-effect of this > is that all WeakPtr will in fact be MTWeakPtr, but there should be few > of them compared to the regular pointers, so the penalty for going to > the AspectStore should overall not be too big. I don't like the weak ptrs are always MT ptrs setup. I don't have a problem with jumping through the aspect store but the logic should stay the same. Let me change things back to the original order/sequence and think about it, you can't switch to the aspect store that easy because nothing inside OpenSG really stores a weak ptr object and before we start to mess around with it I want to be sure we absolutely have to ;) kind regards gerrit ------------------------------------------------------------------------------ _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
