[cpp-threads] Implicit Conversion for Atomics

Boehm, Hans hans.boehm at hp.com
Tue Jan 29 01:58:39 GMT 2008


[Catching up]

> -----Original Message-----
> From: cpp-threads-bounces at decadentplace.org.uk
> [mailto:cpp-threads-bounces at decadentplace.org.uk] On Behalf
> Of Lawrence Crowl
> Sent: Tuesday, January 22, 2008 11:58 AM
> To: C++ threads standardisation
> Cc: c++std-ext at accu.org; c++std-lib at accu.org
> Subject: Re: [cpp-threads] Implicit Conversion for Atomics
>
> On 1/22/08, Peter Dimov <pdimov at mmltd.net> wrote:
> > > In the October 2007 C++ meeting in Kona, I agreed to write up a
> > > paper on the issues with implicit conversion operators on
> the atomic
> > > types.  My first draft is attached.
> >
> > You state in the "hides cost" section that
> >
> >     An atomic store is generally more expensive than an atomic load.
> >
> > Is this indeed true for the seq_cst constraint?
>
> Good question.  I don't have an immediate answer.
>
It's pretty clearly true on X86 (at least in the absence of SSE, which we still need to understand more completely).  The canonical implementation of SC atomics there is

store -> xchg (includes a fence)
load -> ordinary load (actually mov)

On Itanium, this is also true:
store -> st.rel; mf
load -> ld.acq

On ARM, there isn't much of a difference, though my impression is that fences are relatively cheap, so this isn't a huge deal.

On PowerPC, my impression is that they each include a trailing heavy weight sync, but the store also needs a leading lwsync.  The difference probably isn't huge.

Hans



More information about the cpp-threads mailing list