From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4543 Path: news.gmane.org!not-for-mail From: Matthew Fernandez Newsgroups: gmane.linux.lib.musl.general Subject: Re: 64-bit atomic ops on 32-bit ARM Date: Thu, 6 Feb 2014 10:08:57 +1100 Message-ID: <52F2C489.7090608@nicta.com.au> References: <52F2C1AF.8020903@nicta.com.au> <20140205230605.GG15627@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1391641793 29292 80.91.229.3 (5 Feb 2014 23:09:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 5 Feb 2014 23:09:53 +0000 (UTC) To: Rich Felker , Original-X-From: musl-return-4547-gllmg-musl=m.gmane.org@lists.openwall.com Thu Feb 06 00:10:01 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WBBbS-0005zL-IU for gllmg-musl@plane.gmane.org; Thu, 06 Feb 2014 00:09:58 +0100 Original-Received: (qmail 12103 invoked by uid 550); 5 Feb 2014 23:09:57 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 12095 invoked from network); 5 Feb 2014 23:09:57 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: <20140205230605.GG15627@brightrain.aerifal.cx> X-TM-AS-Product-Ver: SMEX-11.0.0.1191-7.500.1017-20484.001 X-TM-AS-Result: No--11.179500-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Xref: news.gmane.org gmane.linux.lib.musl.general:4543 Archived-At: Ah, so it's used for operating on 64-bit bitfields. Presumably the meaning = of each bit is orthogonal to the others so the atomicity of the write as a whole is irrelevant. Thank= s for the clarification, Rich. On 06/02/14 10:06, Rich Felker wrote: > On Thu, Feb 06, 2014 at 09:56:47AM +1100, Matthew Fernandez wrote: >> Hi all, >> >> The header atomic.h contains a couple of functions for operations on 64-= bit types. Despite their >> name, these do not appear to be atomic to me. For example: >> >> static inline void a_and_64(volatile uint64_t *p, uint64_t v) > > The function name is simply a misnomer. It should be called "atomic > bitclear" (and, for "or", "atomic bitset). That's the only way it's > actually used. In other words we don't care that the and/or operation > on both words happen atomically with respect to one another, only that > each bit individually behaves atomically with respect to being set and > cleared. > > BTW, changing the name and semantics would also allow us to drop from > performing two atomic operations to just performing on atomic > operation (on the word that actually needs to change). This would be a > fairly significant optimization, I think. But for now it's not a bug, > just a missed optimization. > > Rich > ________________________________ The information in this e-mail may be confidential and subject to legal pro= fessional privilege and/or copyright. National ICT Australia Limited accept= s no liability for any damage caused by this email or its attachments.