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?).
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. 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?
Second: the current implementation is GCC >=4.2 only. Are there equivalents for
the other systems we care about (Win, MacOS X)? How about smaller systems,
which
might well become MT real soon now?
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.
The alternative is to blow up the WeakPtr class a little and keep the aspect
index together with the AspectStore*. That way we can reproduce the semantics
and avoid the problem.
Other alternatives? Comments?
Dirk
------------------------------------------------------------------------------
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
