[osg-submissions] Use atomic reference counts

[Mathias Fröhlich]

Robert,

On Wednesday 04 June 2008 11:12, Robert Osfield wrote:
> Wr.t. the Config and Config.in files.  The Atomic implementation is
> done purely in the header, so rather than being a configuration of
> OpenThreads itself (as OpenThreads itself won't actually build/use
> it), it's actually an issue of configuration of the code using the
> header.  I don't yet actually have an idea what the full implication
> of this is, it might be that we have no Config file at all, or move it
> into the OSG side.  However, what happens in we do make Atomic built
> and used internally in OpenThreads....
I would normally agree here.
But the basic trick here is that this *is* *inline*. That means that we do not 
have a function call overhead in some of the implementations. That is the 
gcc/icc one and the sgi one. The sun implementation and the win32 
implementatinon will call library functions anyway. But we can avoid one call 
here.

Given we use compiler intrinsics in some cases that are exposed to the 
optimizers, having them inline will provide the compiler to have the 
opportunity to may be optimize that increments/decrements completely away in 
some cases. I do not know if gcc/icc/CC is far enough to do that, but in 
theory such optimizations are possible - and you would sometimes be surprised 
about what a compiler really does.
This kind of optimization cannot happen if this is an implementation in a 
library.

Sure If such a configure option can be encapsulated into the prebuilt sources, 
this should be done. But under some conditions this will just make sense to 
have it in a config file. This condition is met at least if such a 
configuration changes the api of a class - that is also the signatures of the 
calls (Matrix-Matrix[df]) or if it changes the class layout.

> I must admit I'm not entirely comfortable with header files containing
> build configurations - its something the OSG has so far not utilised,
> instead the build system itself toggles on/off features.  And for
> items like Matrix mapping to Matrixf/Matrixd this is configured via
> the build system, but this in turn means the application has to use
> the same setting that the OSG was built with - to solve this for P3D
> and VPB I've used Cmake to query the option the the OSG lib was built
> with.  Is this better or worse than having headers?

I have this kind of change, to move that matrix selection into a header in 
preperation also.
IMO it is *way* better to have a installed library shared object match the 
headers without any commandline define that is required to make it even link 
with the library...

So all in all I would vote for such a Configure file.

Greetings

MAthias


-- 
Dr. Mathias Fröhlich, science + computing ag, Software Solutions
Hagellocher Weg 71-75, D-72070 Tuebingen, Germany
Phone: +49 7071 9457-268, Fax: +49 7071 9457-511
-- 
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Florian Geyer,
Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Prof. Dr. Hanns Ruder
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196