From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9752 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH 1/2] add 64bit atomics on top of 64bit ll/sc primitives Date: Sun, 27 Mar 2016 18:27:45 -0400 Message-ID: <20160327222745.GD21636@brightrain.aerifal.cx> References: <1459113619-24090-1-git-send-email-koorogi@koorogi.info> <1459113619-24090-2-git-send-email-koorogi@koorogi.info> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1459117682 25849 80.91.229.3 (27 Mar 2016 22:28:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Mar 2016 22:28:02 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9765-gllmg-musl=m.gmane.org@lists.openwall.com Mon Mar 28 00:28:01 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1akJA9-0004nl-LH for gllmg-musl@m.gmane.org; Mon, 28 Mar 2016 00:28:01 +0200 Original-Received: (qmail 23606 invoked by uid 550); 27 Mar 2016 22:27:58 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 23588 invoked from network); 27 Mar 2016 22:27:57 -0000 Content-Disposition: inline In-Reply-To: <1459113619-24090-2-git-send-email-koorogi@koorogi.info> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9752 Archived-At: On Sun, Mar 27, 2016 at 04:20:18PM -0500, Bobby Bingham wrote: > --- > src/internal/atomic.h | 28 ++++++++++++++++++++++++++++ > 1 file changed, 28 insertions(+) > > diff --git a/src/internal/atomic.h b/src/internal/atomic.h > index 6f37d25..43a8a00 100644 > --- a/src/internal/atomic.h > +++ b/src/internal/atomic.h > @@ -99,6 +99,34 @@ static inline void *a_cas_p(volatile void *p, void *t, void *s) > > #endif > > +#ifdef a_ll_64 > + > +#ifndef a_and_64 > +#define a_and_64 a_and_64 > +static inline void a_and_64(volatile uint64_t *p, uint64_t v) > +{ > + uint64_t old; > + a_pre_llsc(); > + do old = a_ll_64(p); > + while (!a_sc_64(p, old & v)); > + a_post_llsc(); > +} > +#endif > + > +#ifndef a_or_64 > +#define a_or_64 a_or_64 > +static inline void a_or_64(volatile uint64_t *p, uint64_t v) > +{ > + uint64_t old; > + a_pre_llsc(); > + do old = a_ll_64(p); > + while (!a_sc_64(p, old | v)); > + a_post_llsc(); > +} > +#endif I think we can do without these. a_and_64 and a_or_64 are simply misnamed (they're only usable as atomic bitset/bitclear, not necessarily atomic on the whole 64-bit unit since they only operate on one bit at a time) and I don't think there's any measurable gain to be had by doing them with 64-bit hardware atomics. They'll probably be dropped at some point in the future anyway; malloc is essentially the only user. Rich