Re: [osg-users] Static Variables cause of OS X Multi Threading Bugs

Tue, 25 Jul 2006 13:38:33 -0700 

Robert,
I agree that setting it to 32 would delay dealing with this problem; however, I have implemented and proven the solution below. 


	Are there any specific problems with that solution that I should be  
aware of before I submit a patch?


Dan

On Jul 25, 2006, at 4:05 PM, Robert Osfield wrote:


Hi Daniel,

I think the simplicist thing right now would be to set the intialize
size of GL object delete buffers and per context extension buffers to
a fixed size, say 32.  We more than ever will be needed, the cost of
doing so would be just a bit of extra memory.

osg::Texture::TextureObjectListMap really needs change from a std::map
into a fixed sized std::vector<> too.

The per context buffers in scene graph itself should work fine as they
arn't statics and be safely set up after the max number of contexts is
set up.

Robert.

On 7/25/06, Daniel Larimer <[EMAIL PROTECTED]> wrote:

Robert,

        Perhaps what we really need is a way to dynamically change  
the max

number of display lists without incurring the cost of a mutex.

        Solution:
                class DisplaySettingsListener {   public: virtual
displaySettingsChanged() = 0; };

                Add std::list<DisplaySettingsListener*> to  
DisplaySettings
                Have buffered_value inherit the  
DisplaySettingsListener interface

and add itself to the display settings list

                Every time setMaxNumContexts() is called it will  
notify all of the

listeners.

        Cost:

                One additional pointer for each object that needs  
notified.



        While I believe that there is a way to control the link  
order of
static variables via build options, my experience has been that it  
isn't
        very reliable or friendly to 3rd party developers to  
require special
build/link options.  I have fought these kind of issues on OS X  
before,
        a solution like I mentioned above will work everywhere at  
minimal cost.


Dan

On Jul 25, 2006, at 3:29 PM, Robert Osfield wrote:

> Hi Daniel,
>
> So good detective work.
>
> Is it possible to get OSX to initialize like other OSs?
>
> If not then we'll need to register all the buffers to be later

> initialized to the correct size.  Will need to think more about  
this.

>
> Robert.
>
> On 7/25/06, Daniel Larimer <[EMAIL PROTECTED]> wrote:
>> Robert,
>>         That is effectively the 2nd line executed in main and I
>> set num ==
>> 10 for my application so I know that I haven't hit 10.
>>
>>         Upon closer inspection of include/osg/buffered_value I
>> think I have
>> identified the REAL problem.
>>

>>         There is a difference between Linux and OS X when it  
comes to

>> allocating static variables.  On OS X the static variables such as
>>         s_extentions get allocated BEFORE main(), but Linux
>> doesn't allocate
>> them until their first reference.
>>
>>         Further testing reveals that Drawable::getExtensions(),
>> Shader::flushDeleted...(), and several other places are still
>> crashing even with
>>         my patch.
>>
>>         The solution to this problem is non-trivial and would
>> require some
>> form of direct initialization of these values OR some way to set

>> DisplaySettings::instance()->getMaxNumberOfGraphicsContexts()  
before

>> main().
>>
>>         I put a print statement in the constructor of
>> buffered_value to see
>> when it is initialized and to what size.  I then put a print
>> statement at the first line in main(), here is the out put.
>>
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1
>> buffered_value size: 1

>> [thread: (?)] [CoveAppInit.cpp:27 in CoveAppInit] Initializing  
static

>> Cove objects...
>> [thread: (?)] [AutoreleasePool.cpp:143 in init] Created static
>> AutoreleasePool stack.

>> [thread: (?)] [AutoreleasePool.cpp:29 in AutoreleasePool]  
Created new

>> AutoreleasePool at address 0xa422e30.
>> [thread: (?)] [CoveAppInit.cpp:34 in CoveAppInit] Finished
>> initializing static Cove objects.
>> [thread: (?)] [cove.cpp:15 in main] main
>>
>>
>>         Ideas?
>>
>> Dan
>>
>> On Jul 25, 2006, at 2:36 PM, Robert Osfield wrote:
>>
>> > On 7/25/06, Robert Osfield <[EMAIL PROTECTED]> wrote:

>> >> I realise this is an unsual caveat of multi-threaded multi- 
context

>> >> work, but this its a small hurdle which gains you much better
>> >> performance - otherwise you have mutex commonly access methods
>> which
>> >> would kill performance.
>> >
>> > I forgot to mention the magic line is:
>> >

>> >  osg::DisplaySettings::instance()- 
>setMaxNumberOfGraphicsContexts

>> (num)
>> >

>> > osgProducer::OsgCameraGroup sets atomatically this for you in  
its

>> > constructor, so as long as you construct it before loading the
>> scene
>> > graph then everything is fine.
>> >
>> > Robert.
>> > _______________________________________________
>> > osg-users mailing list
>> > [email protected]
>> > http://openscenegraph.net/mailman/listinfo/osg-users
>> > http://www.openscenegraph.org/
>>
>> _______________________________________________
>> osg-users mailing list
>> [email protected]
>> http://openscenegraph.net/mailman/listinfo/osg-users
>> http://www.openscenegraph.org/
>>
> _______________________________________________
> osg-users mailing list
> [email protected]
> http://openscenegraph.net/mailman/listinfo/osg-users
> http://www.openscenegraph.org/

_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/


_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/


_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/






















					Reply via email to