Hi, On Sun, 2009-03-29 at 15:10 -0500, Dirk Reiners wrote: > Hi Gerrit, > > Gerrit Voß wrote: > > Hi, > > > > ok, after thinking a little and fixing my initial rather brain dead > > tries ;), coming back to the initial problem set ;) > > Sometimes it actually does make sense to stop and think, doesn't it. ;) > > > yes it should have had. With the change to single ref count op > > locations and the spinlock so that the refcount state can only > > be seen in a consistent form I hope that should be gone. > > it looks like it should work fine now, thanks! > > I'm just not too excited about the spin lock solution (BTW, why are the masks > called SplinLock? Is that a joke that I'm not getting or just a typo?).
typo > First: it's a spinlock. Admitted, it's a lock per FC, which is only active > during RefCount adjustment, so contentions is probably not going to be a big > problem. But the __sync_fetch_and_or primitive is probably not a cheap call > on > an MP system, as it requires cross-processor synchronization, so if we get > around it I'd prefer that. hmm, probably, but probably not. I have to check the generated assembler code, currently it is just in the 'get it working form'. If the generated assembler deviates to much I can still replace it by inline assembler code. In the end it should have roughly the performance of the ref count operations because the difference is just the op (add vs or). It is also roughly along the lines what the linux kernel is using for their spinlocks, except they use add and a separate value as they want it to be a bit more fair. > Sideline: you use the high bit of the FC ID as the > flag. Did you secure that by masking it out in the getID call, so that apps > don't see it? I couldn't find that in your commits, did I miss it? earlier, it was one of the things I hopefully got right without to much thinking ;) As I had to fix the original backref problem quite fast, it really broke something, it went in with these changes. > Second: the current implementation is GCC >=4.2 only. yes, but that is because that is the only thing I have access to at home. As it is not in a very crucial path right now I was more for not breaking a build than guessing it for other platforms. I will update the rest today in office where I can verify that it builds ;) > Are there equivalents for the other systems we care about (Win, MacOS X)? Win actually has it longer in the convenient form of the interlockedxxx intrinsic functions. OS X, gcc 4.2 is unfortunately only optional right now so we might have to go back to assembler for a second, but it's an Intel anyway so that should not be to hard. > How about smaller systems, which might well become MT real soon now? Hmm, these are processor feature to make MT reasonably useful so I would expect new processors to have them, these are old features. So if the compiler does not support a convenient intrinsic back to assembler it is. Given that on smaller devices Linux is not an unusual OS I would not expect to much trouble. > So if we can find an alternative that might be preferable. > > We already mentioned just dropping WeakPtrs and only having MTWeakPtrs. Given > the rarity of WeakPtrs I'm not sure what the problem with doing that really > is. > Admitted, from an aesthetics point of view it's a symmetry break, which i > don't > like very much either. But if we can avoid a penalty for the 99% case with it > I > can accept it. > hmm again yes and no. You shift at least part of your penalty from only rarely used during ref count ops to every single frame (no light without a weak ptr). So I'm really not too sure what the result in the end would be. Breaking symmetry is one part, what I'm more concerned about is not having a base MFFCPtr SFFCPtr everything else derives from. But actually I'm not that passionate about it, so if you really want to, change it. kind regards, gerrit ------------------------------------------------------------------------------ _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
