This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: should sync builtins be full optimization barriers?


On Mon, Sep 12, 2011 at 20:40, Geert Bosch <bosch@adacore.com> wrote:

> Assuming that statement is true, that would imply that even for relaxed
> ordering there has to be an optimization barrier. Clearly fences need to be
> used for any atomic accesses, including those with relaxed memory order.
>
> Consider 4 threads and an atomic int x:
>
> thread 1 ?thread 2 ?thread 3 ?thread 4
> -------- ?-------- ?-------- ?--------
> ?x=1; ? ? ?r1=x ? ? ?x=3; ? ? ?r3=x;
> ?x=2; ? ? ?r2=x ? ? ?x=4; ? ? ?r4=x;
>
> Even with relaxed memory ordering, all modifications to x have to occur in some particular total order, called ?the modification order of x.
>
> So, if r1==2,r2==3 and r3==4,r4==1, that would be an error. However,
> without fences, this can easily happen on an SMP machine, even one with
> a nice memory model such as the x86.

How?  (Honest question).  All stores are to the same location.  I
don't see how that can happen without processor fences, much less
without optimization fences.

Paolo


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]