Hi Daniel and Mark,
I don't think this particular issue is actually down to static
initialization issue, its rather just a thread issue related to resize
arrays that arn't big enough. So its really down to how do you make
the resize thread safe or how do you make them big enough to start
with.
I think the lack of crashes elsewhere other than OSX is a bit down to
luck, but also part down to the fact that global arrays in questions
used to intialized to a default size of 4, but this was taken down to
1 quite recently:
http://cvs.openscenegraph.net/viewcvs/src/osg/DisplaySettings.cpp?r1=1.35&r2=1.36
I did do lots of testing with my dual core dual graphics card system
over the last month, but alas it didn't pick up on the problem.
Daniel's OSX testing did uncover it, alas a little too late to get
into 1.1, but still we can get it resolved properly this time.
I think the DisplaySettingsListener is certainly a useful additional
to the global OpenGL object delete buffers and global extension
structures, although bumping the default max number of context back up
to something like 32 will probably hide the problem for a long time.
The other sized is the per context buffers in the scene graph, and I
don't feel these are best served by DisplaySettingsListener purely on
performance grounds, when database paging peformance is important, and
hanging a lot more calls and mutexes into the not going to be helpful.
One has to remember that multi-contex work is still in the minority
for OSG users too, so overheads for them for something they'll never
use would be a pain.
Robert.
On 7/26/06, Daniel Larimer <[EMAIL PROTECTED]> wrote:
One of many similar examples can be found here.
src/osg/Drawable.cpp:783
You suggested that using a singleton pattern may solve this issue and
I agree it
could because the buffer wouldn't be allocated / updated until the
first access; however,
there may be some performance considerations such as:
- Extra check for NULL before every access (or init case)
- Extra function call on the stack
- You still have a race condition if the first access could come from
multiple threads which
would put a mutex in the way
At the very least you would have to centralize the many (20+?) static
objects so that you could
control with one call when they all get initialized.
What are the downsides to the patch I submitted (submissions list)
with a DisplaySettingsListener object that solves this
problem and expands functionality across all platforms by supporting
dynamic changes to the max number of contexts?
Total cost is 1 extra pointer, plus some init & cleanup overhead.
Dan
On Jul 25, 2006, at 6:44 PM, [EMAIL PROTECTED] wrote:
> On Tue, 2006-07-25 at 15:23 -0400, Daniel Larimer wrote:
>>
>> 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.
>
> Interesting. There should be no functional difference since this
> behavior is defined by the C++ language. See the language reference
> section 3.6.2 [basic.start.init] for details.
>
>> On OS X the static variables such as s_extentions get allocated
>> BEFORE
>> main(), but Linux doesn't allocate them until their first reference.
>
> C++ mandates that a static variable is initialized the first time
> control passes through its declaration. Both of these OS behaviors are
> permitted by C++ with some caveats. Again see [basic.start.init] and
> related sections.
>
> Can you point me at the static variables that are misbehaving? I'd
> like
> to take a quick look at the situation and offer some help.
>
> Regards,
> Marcus
>
>
> --
> Mark Barnes
> COLLADA Project Lead, tel:+1.650.655.7342
> Sony Computer Entertainment America
> http://research.scea.com
>
> _______________________________________________
> 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/
