From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7659 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Deduplicating atomics written in terms of CAS Date: Sun, 17 May 2015 12:28:54 -0400 Message-ID: <20150517162854.GN17573@brightrain.aerifal.cx> References: <20150517045536.GA25046@brightrain.aerifal.cx> <20150517061430.GL17573@brightrain.aerifal.cx> <1431848239.11628.3.camel@inria.fr> 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 1431880152 9430 80.91.229.3 (17 May 2015 16:29:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 17 May 2015 16:29:12 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7671-gllmg-musl=m.gmane.org@lists.openwall.com Sun May 17 18:29:12 2015 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 1Yu1R7-0004aP-9v for gllmg-musl@m.gmane.org; Sun, 17 May 2015 18:29:09 +0200 Original-Received: (qmail 3751 invoked by uid 550); 17 May 2015 16:29:08 -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 3730 invoked from network); 17 May 2015 16:29:07 -0000 Content-Disposition: inline In-Reply-To: <1431848239.11628.3.camel@inria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7659 Archived-At: On Sun, May 17, 2015 at 09:37:19AM +0200, Jens Gustedt wrote: > Am Sonntag, den 17.05.2015, 02:14 -0400 schrieb Rich Felker: > > - a_and_64/a_or_64 (malloc only; these are misnamed too) > > I should have checked the use before my last mail. They are > definitively misnamed. > > Both uses of them look ok concerning atomicity, only one of the a_and > or a_or calls triggers. > > The only object (mal.binmap) to which this is applied is in fact > volatile, so it must actually be reloaded all the time it is used. > > But in line 352 the code uses another assumption, then, that 64 bit > loads always are atomic. I don't see why this should hold in general. I don't think there's such an assumption. The only assumption is that each bit is read exactly the number of times it would be on the abstract machine, so that we can't observe inconsistent values for the same object. Lack of any heavy synchronization around reading the mask may result in failure to see some changes or seeing them out of order, but it doesn't matter: If a bin is wrongly seen as non-empty, locking and attempting to unbin from it will fail. If it is wrongly seen as empty, the worst that can happen is a less-optimal (but would have been optimal an instant earlier) larger chunk gets split instead of using a smaller one to satisfy the allocation. Of course it's an open question whether the complex atomics and fine-grained locking in malloc help or hurt performance more on average. I'd really like to measure this at some point. Overhauling malloc to try to get significantly better multi-threaded performance without the fragmentation-optimality sacrifices other mallocs make is a long-term goal I have open. > We already have a similar assumption for 32 bit int all over the > place, and I am not too happy with such "silent" assumption. For 64 > bit, this assumption looks wrong to me. I agree I wouldn't be happy with such an assumption, but I don't think it's being made here. > I would be much happier by using explicit atomic types and atomic load > functions or macros everywhere. For normal builds these could be dummy > types made to resolve to the actual code that we have, now. But this > would allow to have hardening builds, that check for consistency of > all atomic accesses. There is no way to do an atomic 64-bit load on most of the archs we support. So trying to make it explicit wouldn't help. Rich