From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9649 invoked by alias); 19 Nov 2012 05:46:46 -0000 Received: (qmail 9638 invoked by uid 22791); 19 Nov 2012 05:46:45 -0000 X-SWARE-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-pb0-f47.google.com (HELO mail-pb0-f47.google.com) (209.85.160.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 19 Nov 2012 05:46:40 +0000 Received: by mail-pb0-f47.google.com with SMTP id un1so1652139pbc.20 for ; Sun, 18 Nov 2012 21:46:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=D53uyYaoCLieLgK4eCamw83ukezppSHeKCtZrEfgRNg=; b=YaDutoFt/uO5iXwttp5Z/cDeWxygns3Xih2KiVE5fkdeFkYBz6+MHKjoolRM2r5G1A +YAOSMOUJGHeb76Hi0tF6J2qAc4CrXIyyApXForfiVEL+yb19WB+/bsKgmtftFK28T7q jCfgqO43T2CxWGXGE4sEGntymV9TgiDHnI2nnU8MrkWaPHFtXVZa5eL4JTvVDsqkBLoA i1+oZw2dtEuAO6WSC4uAoutqq+jmRMgsfmp3ZwY6m/xxaBrH5xj6BLdt4Zm5n30Lrsmv MC766oRhmHRBd8rU1HHqnDmzqZwp2xa7Vavt5FY+v65Pc9JfhADG8fs2a+r32iiGUm3k hvLw== MIME-Version: 1.0 Received: by 10.66.85.67 with SMTP id f3mr33129221paz.0.1353303999622; Sun, 18 Nov 2012 21:46:39 -0800 (PST) Received: by 10.68.54.133 with HTTP; Sun, 18 Nov 2012 21:46:39 -0800 (PST) In-Reply-To: <1353303536.52730.YahooMailNeo@web165001.mail.bf1.yahoo.com> 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> <1353303536.52730.YahooMailNeo@web165001.mail.bf1.yahoo.com> Date: Mon, 19 Nov 2012 05:46:00 -0000 Message-ID: Subject: Re: __sync_fetch From: Ian Lance Taylor To: Hei Chan Cc: "gcc-help@gcc.gnu.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmGJrvVgSSMAwStR0W1IsPpQ00QaTbWwXtoD6ua1uD/987fPwr3LzhLls+X8H1Nc/5dp3zweyRqgJ7yI0aP+EHIYkVFkowYXWjW6TeeUfFbKmxhkhjtGv0i1+HgymNOty2s7tUjYl210DlKL6l5vXk//Z3jqiNfnJT51jkNSJ0+Vui2yZGTn1JRltkp6p50eqfZR7Dx 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/msg00146.txt.bz2 On Sun, Nov 18, 2012 at 9:38 PM, Hei Chan wrote: > > I am not sure why the casting in your example will cause any issue as I t= hought without __pack__, the variable a will be aligned by gcc, no? 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)? In my example, a is a char array. A char array is not required to be aligned to an 8-byte boundary. It's true that GCC will align the variable a, but it may align it to an odd address. So if I cast the array a to long*, I may get a long* that is not aligned to an 8-byte boundary. Ian > ----- Original Message ----- > From: Ian Lance Taylor > To: Hei Chan > Cc: > Sent: Sunday, November 18, 2012 9:14 PM > Subject: Re: __sync_fetch > > On Sun, Nov 18, 2012 at 9:03 PM, Hei Chan wrot= e: >> You mean: >> 1. the variable I am trying to read doesn't belong to a packed struct; a= nd > > Yes. > >> 2. I am not casting to something not 8 byte long on a 64 bit machine? 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 > char a[16]; > 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. 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 wro= te: >>> 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. 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? Unde= r 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 >>>>> 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 >>>>>> 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 >>>>> >>>> >>> >> >> >