Re: [boost] [atomic, x86] need another pair of eyes

Subject: Re: [boost] [atomic, x86] need another pair of eyes
From: Holger Grund (holger.grund_at_[hidden])
Date: 2012-12-19 12:37:39

> >> > All uses of READ_BARRIER or WRITE_BARRIER seem wrong, though.
> >> > READ_WRITE_BARRIER is needed in all places where these are used.
> >>
> >> Why? The intention was to prevent outer reads and writes being
> >> reordered with the atomic op. Did I miss something?
> >
> >
> > The acquire/release semantics are not specific to reads or writes. An
> > acquire load should prevent subsequent writes from being reordered so
> > as to precede it, and a read barrier doesn't do that, I think.
> 
> I suppose you're right. I was under impression that _ReadBarrier and
> _WriteBarrier intrinsics were equivalent to the acquire and release
compiler
> fences but reading their docs now this doesn't seem to be correct. Only
> _ReadWriteBarrier has the comment that the compiler doesn't reorder
> operations across it. Thank you, I will correct the code.
> 
It's been quite a while since I had my hands on VC' codegen, but I'm fairly
certain the sole purpose of these intrins is to prevent reordering in the
compiler. They don't result in any code being emitted directly.

I guess, in real-world cases it's rather unlikely to make a difference as
there's usually some expression with side-effects in between memory
operations or there are volatile accesses. However, these intrinsics are
needed to avoided things like redundant-load-after-load optimizations.

E.g.:
// address-taken globals
extern int x;
extern int y;
void foo() {
  int lx = x;
  int ly = y;
  use(x);
  sync_operation();
  lx = x;
  use(x);
}

If use and sync_operation have no side effects, the second load of x would
usually be optimized out. The initial load might be ordered after the
sync_operation. This is where the _*Barrier intrinsics come in.

-hg