[Gc] Should libatomic_ops be inside bdwgc?

Petter Urkedal urkedal at nbi.dk
Thu Aug 11 15:00:56 PDT 2011


On 2011-08-11, Petter Urkedal wrote:
> On 2011-08-11, Petter Urkedal wrote:
> > On 2011-08-10, Boehm, Hans wrote:
> > > The libatomic_ops API should be stable at this point.  I would
> > > discourage major changes, since I think it's obsoleted by C++0x and
> > > C1x atomics, which can be viewed as another, much more careful,
> > > iteration on libatomic_ops.
> > > 
> > > In the slightly longer term, bdwgc should also work with C++0x/C1x
> > > atomics instead of libatomic_ops.  In the even longer term, we should
> > > phase out libatomic_ops.  In the short term, we have too few
> > > implementations of the C++0x atomics, and they may still be too
> > > immature.
> > 
> > This is really good, as it will presumably be written by the compiler
> > writers.  I can see GCC already have experimental support.  I think it
> > usually takes some time before new C/C++ standards are widely adopted.
> > One possibility in the meantime is to make a thin wrapper within
> > "libatomic_ops" which defines all atomic types up to long and
> > "int_least32_t" as "struct { AO_t value; }" and implement the function
> > in terms of the corresponding libatomic_ops functions.
> 
> Attached is untested sketch of what I had in mind, with various loose
> ends (TODO, FIXME, CHECKME).

The first CHECKME, seem clear:  We'll need to leave out some of the
integer types on 32 bit platforms, esp. due to sign-issues during
conversion to and from AO_t.  I guess a real implementation would
implement any double-word integers with mutexes if necessary.

P.S.  Hans, no need to comment now if you're on vacation or otherwise
busy.  I'll just leave this for later.


More information about the Gc mailing list