On Sun, Nov 18, 2012 at 12:10 AM, Hei Chan <structurechart@xxxxxxxxx> 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@xxxxxxxxxx> > To: Hei Chan <structurechart@xxxxxxxxx> > Cc: "gcc-help@xxxxxxxxxxx" <gcc-help@xxxxxxxxxxx> > Sent: Sunday, November 18, 2012 12:07 AM > Subject: Re: __sync_fetch > > On Sat, Nov 17, 2012 at 11:04 PM, Hei Chan <structurechart@xxxxxxxxx> 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 >
