[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