[osg-users] Refactoring DatabasePager NeedToRemove string flagging technique

Robert Osfield robert.osfield at gmail.com
Fri Nov 20 01:58:08 PST 2009


Hi Chris,

On Mon, Nov 2, 2009 at 4:05 PM, Chris 'Xenon' Hanson
<xenon at alphapixel.com> wrote:
>  I'm kind of an old-school C-flavor programmer, so my instinctive response is rather
> C-like. I don't like bloating people's in-memory objects, so I'd lean towards defining a
> 32-bit flag member on class Node called something like _ephemeralInternalStateFlags. This
> would not be saved or restored, and the definitions of each flag bit would be enumerated
> as 1<<n enums in the Node class header. Code outside of the OSG core distribution would be
> prohibited (by policy, can't really enforce it in the compiler) from defining and
> utilizing these flag bits, but code within OSG core could. The first bit allocated would
> be used to replace the NeedToRemove indicator.

I'm not sure whether this is really needed.  The NeedToRemove trick in
DatabasePager is very specific to a piece of code embedded in
DatabasePager it has no value outside this specific bit of code, and I
believe it's not appropriate to build algorithm specific such support
into the core OSG.

>  Also, while the read-modify-write cycle used to toggle just one bit of a flag is not as
> fast as the blind-write cycle used when you dedicate a whole boolean variable (and consume
> more memory), both the setting operation AND the testing operation should be faster than
> the current string-marking technique.
>
>  If Robert has no objections to this solution, I'll code it up quick and share it.

I think the right thing to do is nothing in the core OSG, and look at
the specific DatabasePager algorithm to retain the O(1) cost of the
check that I was using, with the bugs with handling multiple
viewpoints.


>  I'm also concerned about the amount of very similar-but-not-quite-the-same code between
> DatabasePager::capped_removeExpiredSubgraphs and
> DatabasePager::expiry_removeExpiredSubgraphs. I'd like to refactor that to DRY (Don't
> Repeat Yourself) it out a bit as I'm implementing some code of my own that needs to
> cleanly dispose of some PagedLOD children. But, I don't understand why there are
> differences in the disposal technique between them (one calls
> _fileRequestQueue->updateBlock() directly, one sets a local flag and calls updateBlock()
> at the end of the operation, etc).

Both methods exists while we test the new
capped_removeExpiredSubgraphd , once it's fully tested and debugged
the old expiry_removeExpiredSubgraphs method will be removed
completely this neatly avoiding the issue of similar code.

Robert.


More information about the osg-users mailing list