subject:"\\\\\\\[Flightgear\\\\\\\-devel\\\\\\\] OSG caching"

Re: [Flightgear-devel] OSG caching and other OSG issues

2012-04-01 Thread Mathias Fröhlich


Hi,

I try to catch up on things past an other busy week.

On Thursday, March 29, 2012 00:22:46 ThorstenB wrote:
 Mathias, maybe you can have a look at the simgear changes. Maybe you see
 a way to improve this even further - i.e. do we still need all these
 cache maps? Or could we simply rely on some OSG cache in some places?

Just looking quick over what you checked in, I think that this needs some 
improovements:

The change just returns pointers to objects you get from the observer_ptr.
In general, this is not exactly thread safe. I do not see currently if you can 
ensure from a higher level that this is not a problem or not.

In general consider the following situation:

Thread 1 has an observer_ptr to A.

Thread 2 owns the last reference to A.

Thread 1 gets the still valid raw pointer to A from the observer_ptr.

Thread 2 releases the last reference to A and deletes it.

Thread 1 assigns the raw pointer to a ref_ptr. This probably ends in a 
segfault.


If you work with weak pointers/observer_ptr you need to use the lock method. 
That one gives you a atomically a dead or alive ref_ptr to A. If you have this 
ref_ptr in our hands, you own a thread safe reference which makes sure that 
nobody deletes the object. If your ref_ptr is invalid. An other one was faster 
on unreferencing.
In effect this groups step 3 and 5 into an atomic operation which can not be 
intercepted by step 4 in the example above.

So, if you use this kind of weak stuff, you need to ensure that all the call 
chain from getting the ref_ptr from any cache down to adding this object to 
the scenegraph does not use raw pointers. Also the initial ref_ptr in this 
chain must be gained by observer_ptr::lock().

Regarding the effects, I don't think we can rely on any caching in osg since we 
do not currently use any osg based loader mechanism to gain these objects.
At least nothing that I know of.

Greetings

Mathias

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] OSG caching and other OSG issues

2012-04-01 Thread ThorstenB

Am 01.04.2012 18:25, schrieb Mathias Fröhlich:
 If you work with weak pointers/observer_ptr you need to use the lock method.

Ok, you're absolutely right. I wasn't aware of the lock method before, 
indeed it has to be used here. I'll push a change. Thanks for reviewing 
this!

cheers,
Thorsten

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] OSG caching and other OSG issues

2012-03-28 Thread ThorstenB

Hi,

I've pushed a fix for a larger memory issue, mainly affecting
effects/texture images, but also other objects. Once loaded, these stuck
in memory until shutting down flightgear - so memory consumption was
continually growing when flying larger distances.

Probably wasn't much of an issue initially, when we only had few or
generic textures. Now, with lots of custom models and eye candy, we
obviously should be able to drop stuff again.

We've discussed this about a year ago. Tim suggested using observer
pointers instead of references in the cache maps. The discussed patch
was never pushed to sg/next though, since I was running into stability
issues with OSG 2.8.3. Since we don't support OSG 2.8.3 any longer, I've
revived this again and changes are in simgear now. Keeps memory
consumption a lot lower. I'm still seeing a slight memory growth when
moving - but by far, it's not as bad as it was.

Simple test is to relocate-on-ground to a series of airport locations
and watch process memory.

Mathias, maybe you can have a look at the simgear changes. Maybe you see
a way to improve this even further - i.e. do we still need all these
cache maps? Or could we simply rely on some OSG cache in some places?

cheers,
Thorsten

Am 03.05.2011 21:49, schrieb ThorstenB:
On Mon, Apr 18, 2011 at 9:55 AM, Tim Mooretimoor...@gmail.com wrote:
On Sun, Apr 17, 2011 at 6:10 PM, ThorstenBbre...@gmail.com wrote:
There is
a global cache in simgear/makeEffect.cxx (effectMap), and it has no
condition to ever drop anything. So, created effects always stay in
memory until shutdown - hence also their textures.

It seemed like a good idea at the time :)
The Effect cache could be changed to use osg::observer_ptr, which is a
weak pointer.

Good idea. Here's a patch using observers instead of references for
caching. Puts some live into the effect/texture destructors - so these
can finally free up some memory once the objects are no longer used
anywhere:
http://www.gitorious.org/~thorsten/fg/thorstenbs-simgear/commit/71d14629076b3a56c40cc0309b42b3a22d579bec

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

22 matches

Mail list logo