[osg-submissions] Use atomic reference counts

[Robert Osfield]

HI Mathias,

I agree with the OpenThreads first approach so we can focus on this right now.

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 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?

One thing that doing a runtime based query of the build options is
that it avoids issues of mixing a lib built with one set of options
against the headers that are out of sync with them.

Thoughts?
Robert.



On Wed, Jun 4, 2008 at 9:39 AM, Mathias Fröhlich
<M.Froehlich at science-computing.de> wrote:
>
> Hi Robert,
>
> On Tuesday 03 June 2008 14:46, Robert Osfield wrote:
>> I'm just beginning the review of your submission, not far in yet but
>> have a question/query.  Looking at src/osg/Referenced.cpp I see that
>> it contains two sets of changes - the atomic reference count changes
>> that are to be expected, and then changes to the observer management
>> which looks to be a knock on change required because the Mutex
>> _refMutex disappears along with the introduction of the atomic ref
>> counts.
>>
>> My inclination would be to separate these two sets of changes, for
>> instance leave _refMutex in place and leave the old observer code in
>> place, then do a second submission that removes the observer code's
>> dependence on _refMutex.  The observer code itself that you have
>> introduced does leave me a bit perplexed on a first read through, I
>> presume the complexity is down to the attempt at avoiding the
>> _refMutex, but suspect that as such one could still introduced
>> potential threading problems over initialization of the observer set
>> structure.   It might be that your code is safe, but it's complex
>> enough that I can't say this right away.  Perhaps a static ref mutex
>> might be sufficient for this particular support.
>>
>> Thoughts?
>
> I can seperate that functional changes.
>
> I would suggest to first care for the ground work in openthreads.
> That is wee need:
> - an atomic integer counter class,
> - an atomic pointer assignment.
> That also covers the config include header stuff.
>
> Once we have worked out how you like to have that, we can start using that in
> Referenced.
>
> So, the ground work:
> We have a configure time check if we have some kind of compiler intrinsics or
> library support for smp atomic integer increment/decrement operations.
> Also we will need an atomic 'compare and exchange' operation on pointers.
>
> cmake will then generate that <build>/include/OpenThreads/Config file from the
> <src>/include/OpenThreads/Config.in. Note that this file needs to be
> installed later into the include directory of the installation.
>
> Based on the Config file, the implementation of the atomics are choosen.
> And no, the define you mentioned in the other mail should be right as is. That
> is, if there is no atomic operation on that single integer available, make
> sure that we have an atomic integer using a mutex.
>
> So all the defines in this current Config file are defined when we should use.
> That is 'have a mutex in the atomic' if we 'should use a mutex to make that
> atomic' ...
> Only one of them should be defined, and if non is defined in the end - which
> might be a yet unimplemented configure option - we will assume a single
> threaded case where an atomic integer is just an integer ...
>
> The open question:
> Where do you want to have the Config.in 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
>
>
> _______________________________________________
> osg-submissions mailing list
> osg-submissions at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>