From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4098 invoked by alias); 19 Nov 2012 05:39:07 -0000 Received: (qmail 3636 invoked by uid 22791); 19 Nov 2012 05:39:04 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from nm34-vm1.bullet.mail.bf1.yahoo.com (HELO nm34-vm1.bullet.mail.bf1.yahoo.com) (72.30.239.73) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 19 Nov 2012 05:38:58 +0000 Received: from [98.139.212.149] by nm34.bullet.mail.bf1.yahoo.com with NNFMP; 19 Nov 2012 05:38:57 -0000 Received: from [98.139.212.215] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 19 Nov 2012 05:38:57 -0000 Received: from [127.0.0.1] by omp1024.mail.bf1.yahoo.com with NNFMP; 19 Nov 2012 05:38:57 -0000 Received: (qmail 68247 invoked by uid 60001); 19 Nov 2012 05:38:56 -0000 Received: from [107.3.182.162] by web165001.mail.bf1.yahoo.com via HTTP; Sun, 18 Nov 2012 21:38:56 PST X-Rocket-MIMEInfo: 001.001,SGkgSWFuLAoKVGhhbmtzIGZvciB5b3VyIHJlcGx5LgoKSSBhbSBub3Qgc3VyZSB3aHkgdGhlIGNhc3RpbmcgaW4geW91ciBleGFtcGxlIHdpbGwgY2F1c2UgYW55IGlzc3VlIGFzIEkgdGhvdWdodCB3aXRob3V0IF9fcGFja19fLCB0aGUgdmFyaWFibGUgYSB3aWxsIGJlIGFsaWduZWQgYnkgZ2NjLCBubz_CoCBBbmQgeW91IGFyZSB0cnlpbmcgdG8gZ2V0IHRoZSBhZGRyZXNzIG9mICZhWzBdICh3aGljaCBpcyBmaXhlZCkgYW5kIHRoZW4gY2FzdCB0byBsb25nKiwgc2hvdWxkbid0IGhhdmUgYW55dGhpbmcgZG8BMAEBAQE- References: <1353134056.24702.YahooMailNeo@web165004.mail.bf1.yahoo.com> <1353222284.11967.YahooMailNeo@web165001.mail.bf1.yahoo.com> <1353226253.32891.YahooMailNeo@web165005.mail.bf1.yahoo.com> <1353267089.55438.YahooMailNeo@web165004.mail.bf1.yahoo.com> <1353294140.73855.YahooMailNeo@web165005.mail.bf1.yahoo.com> <1353301408.14218.YahooMailNeo@web165002.mail.bf1.yahoo.com> Message-ID: <1353303536.52730.YahooMailNeo@web165001.mail.bf1.yahoo.com> Date: Mon, 19 Nov 2012 05:39:00 -0000 From: Hei Chan Reply-To: Hei Chan Subject: Re: __sync_fetch To: Ian Lance Taylor Cc: "gcc-help@gcc.gnu.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2012-11/txt/msg00144.txt.bz2 Hi Ian, Thanks for your reply. I am not sure why the casting in your example will cause any issue as I tho= ught without __pack__, the variable a will be aligned by gcc, no?=A0 And yo= u are trying to get the address of &a[0] (which is fixed) and then cast to = long*, shouldn't have anything do with alignment....or do you mean long p = =3D (long)(*a)? Thanks in advance. ----- Original Message ----- From: Ian Lance Taylor To: Hei Chan Cc:=20 Sent: Sunday, November 18, 2012 9:14 PM Subject: Re: __sync_fetch On Sun, Nov 18, 2012 at 9:03 PM, Hei Chan wrote: > You mean: > 1. the variable I am trying to read doesn't belong to a packed struct; and Yes. > 2. I am not casting to something not 8 byte long on a 64 bit machine?=A0 I > thought casting would happen after the variable is stored in register? I'm sorry, I don't know what you mean. By casting I mean something like =A0 char a[16]; =A0 long *p =3D (long *) a; Nothing here makes a aligned. If you want to continue this discussion, please use the mailing list, not private mail to me.=A0 Thanks. Ian > From: Ian Lance Taylor > To: Hei Chan > Sent: Sunday, November 18, 2012 7:26 PM > Subject: Re: __sync_fetch > > On Sun, Nov 18, 2012 at 7:02 PM, Hei Chan wrot= e: >> So the case you mentioned about unaligned cache line shouldn't happen, >> right? > > Unless you are doing something unusual involving casts or packed > structs, that is correct. > > Ian > > >> Just want to check (so that I can shave another few hundreds nano sec in >> my code). >> >> Thanks in advance. >> >> >> ----- Original Message ----- >> From: Ian Lance Taylor >> To: Hei Chan >> Cc: "gcc-help@gcc.gnu.org" >> Sent: Sunday, November 18, 2012 6:57 PM >> Subject: Re: __sync_fetch >> >> On Sun, Nov 18, 2012 at 11:31 AM, Hei Chan >> wrote: >>> I just spoke with my coworker about this.=A0 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 >>> To: Hei Chan >>> Cc: "gcc-help@gcc.gnu.org" >>> Sent: Sunday, November 18, 2012 12:18 AM >>> Subject: Re: __sync_fetch >>> >>> On Sun, Nov 18, 2012 at 12:10 AM, Hei Chan >>> 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?=A0 Und= er 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.=A0 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.=A0 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 >>>> To: Hei Chan >>>> Cc: "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 >>>> wrote: >>>>> >>>>> After searching more for info, it seems like even though on a >>>>>=A0 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 >>>>>=A0 someone elaborate a situation that reading a long variable won't g= et >>>>> 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.=A0 That should be true on any >>>> processors that implements __sync_fetch_and_add in the appropriate >>>> size. >>>> >>>> Ian >>>> >>> >> > >