This is the mail archive of the gcc-help@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: __sync_fetch


Hi Ian,

Thanks for your reply.

How about on a 64-bit Intel processor, I use __sync_fetch_and_*() to write to a long variable, but never use any __sync_*() to read?? Under what situation that I will read something invalid?

Thanks in advance.


Cheers,
Hei


----- Original Message -----
From: Ian Lance Taylor <iant@google.com>
To: Hei Chan <structurechart@yahoo.com>
Cc: "gcc-help@gcc.gnu.org" <gcc-help@gcc.gnu.org>
Sent: Sunday, November 18, 2012 12:07 AM
Subject: Re: __sync_fetch

On Sat, Nov 17, 2012 at 11:04 PM, Hei Chan <structurechart@yahoo.com> wrote:
>
> After searching more for info, it seems like even though on a
>? 64-bit machine, reading a long (i.e. 8 bytes) is one operation, it
> might not give the "correct" value:
> http://gcc.gnu.org/ml/gcc/2008-03/msg00201.html
>
> And so, we have to use __sync_fetch_and_add(&x, 0) to read?
>
> Could
>? someone elaborate a situation that reading a long variable won't get
> the correct value given that all writes in the application use
> __sync_fetch_*()?

If you always use __sync_fetch_and_add(&x, 0) to read a value, and you
always use __sync_fetch_and_add to write the value also with some
appropriate detla, then all the accesses to that variable should be
atomic with sequential consistency.? That should be true on any
processors that implements __sync_fetch_and_add in the appropriate
size.

Ian


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