Re[2]: [Gc] Should libatomic_ops be inside bdwgc?

Ivan Maidanski ivmai at
Wed Aug 17 09:08:27 PDT 2011

Hi Petter and Hans,

Is the current libatomic_ops API sufficient to implement the complete C++0x atomics API? (Or, we don't need to implement all the C++0x primitives, do we?)

A sub-question: what's about CAS? I mean do we need a CAS variant returning old-value to implement the corresponding C++0x primitive?


14 08 2011, 21:56 Petter Urkedal <urkedal at>:
> On 2011-08-14, Ivan Maidanski wrote:
> > Hi Petter,
> >
> > Thank you. I'm really new to Git (and the distributed model), and I'm trying to understand Git best practices. (Having 4 active participants in some one project, I've failed to serialize commit even with forcing them to do rebase on every push, so I've finally decided to leave the commit network as-is.)
> Hi Ivan,
> If you skip the Github model and keep contributor branches, then you
> should be able to rebase yourself just before merging, and use
> "git merge --ff ..." to make sure it's fast-forward.  But as I pointed
> out, there may be something attractive productivity-wise about the
> Github model.  I like the extra channel of communication it brings.
> > About C++0x and lbatomic_ops:
> > You're trying implement C++0x atomic API on top of libatomic_ops and then switch atomic calls in bdwgc to it, right?
> > Could you point me to C++0x atomic API spec, please?
> Yes, that's the intention.  The point is that it may take time to get
> wide implementation across compilers and architectures, so we would
> build on all the porting work which has gone into libatomic_ops in the
> meantime.  Once the calls are converted in bdwgc, we could check for
> atomics.h and fall-back to the libatomic_ops.  My reference was the C1X
> update at
> Petter

More information about the Gc mailing list