On Sun, Nov 18, 2012 at 11:31 AM, Hei Chan <structurechart@xxxxxxxxx> wrote: > I just spoke with my coworker about this. We just wonder whether C++ standard/GCC guarantees all the variables will be aligned if we don't request for unaligned (e.g. __packed__). Yes. 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:18 AM > Subject: Re: __sync_fetch > > 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 >> >
