__sync_fetch

[Ian Lance Taylor]

On Sun, Nov 18, 2012 at 12:10 AM, Hei Chan <structurechart@yahoo.com> wrote:
>
> 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?

On a 64-bit Intel processor, if the 64-bit value is at an aligned
adress, then to the best of my knowledge that will always be fine.  If
the 64-bit value is misaligned and crosses a cache line, then if you
are unlucky I believe that a write can occur in between reading the
two different cache lines, causing you to read a value that was never
written.

I feel compelled to add that attempting to reason about this sort of
thing generally means that you are making a mistake.  Unless you are
writing very low-level code, such as the implementation of mutex, it's
best to avoid trying to think this way.

Ian



> ----- 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
>