From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7711 Path: news.gmane.org!not-for-mail From: Timo Teras Newsgroups: gmane.linux.lib.musl.general Subject: Re: Refactoring atomics as llsc? Date: Wed, 20 May 2015 08:33:23 +0300 Message-ID: <20150520083323.2340cd1b@vostro> References: <20150520051108.GA28347@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1432100027 9410 80.91.229.3 (20 May 2015 05:33:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 May 2015 05:33:47 +0000 (UTC) Cc: musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-7723-gllmg-musl=m.gmane.org@lists.openwall.com Wed May 20 07:33:46 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 1YuwdS-0008SM-T6 for gllmg-musl@m.gmane.org; Wed, 20 May 2015 07:33:43 +0200 Original-Received: (qmail 19818 invoked by uid 550); 20 May 2015 05:33:41 -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 19794 invoked from network); 20 May 2015 05:33:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=ken7rYjleeLlfQJYMHTix68axY/BnRgZI1C6XiC/ltM=; b=mVZrD+65qrFxGjHL9n9/b4Ok0jZQndzoXjEZa1iI1D1P8KZGeYDfgJ20b0rFF87vcL SW5GaQwPmd4RYu1Eu3DFhzZ7WjTRHYmmnzFXJbr2Agn7t4g95m26OJ9PKMDRW8G+2Hck hMlssoIzJTdq6ZH3J7mwAEeBxej3gIKKg/UqA16fdk3cibTfu6H9bxFQWWX24nQZtQx0 VViyRyCTKuzFQMvSUy1QGCzvIDJPNiin4StXTZhZUGV7JcQ/xlbOAuKfm7aTUQUpljWT yUmYeNNTFJxGCmy7C1NMCVhhgvEqY1o3Zv8GA93R0QBfLZtFWpd4rujaTLrhdz15IEQX eENA== X-Received: by 10.152.21.5 with SMTP id r5mr14950330lae.24.1432100009536; Tue, 19 May 2015 22:33:29 -0700 (PDT) Original-Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= In-Reply-To: <20150520051108.GA28347@brightrain.aerifal.cx> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-alpine-linux-musl) Xref: news.gmane.org gmane.linux.lib.musl.general:7711 Archived-At: On Wed, 20 May 2015 01:11:08 -0400 Rich Felker wrote: > Of course the big outlier is x86, which is not llsc based but has > actual atomic primitives at the instruction level. If we defined the > sc() primitive to take 3 args instead of 2 (address, old value from > ll, new value to conditionally store; most archs would ignore the old > value argument) then we could model x86 with ll being a plain load and > sc being cmpxchg to allow any new custom primitives to work using > cmpxchg. Then we would just continue providing custom versions of all > the old a_* ops (a_cas, a_fetch_add, a_inc, a_dec, a_and, a_or, > a_swap) to take advantage of the x86 instructions. These versions > could probably be shared by all x86 variants (i386, x86_64, x32) since > they're operating on 32-bit values and the asm should be the same. I wonder if calling that kind of emulation ll()/sc() would be misleading. load-linked store-conditional has stronger guarantees. sc will fail if the cache-line was invalidated in-between, thread was pre-empted etc. Using cmpxchg can be used to emulate it only when the user is aware of ABA problem (some other thread may have changed the value behind us multiple times). Such emulation is of course ok for a_fetch_add, etc. But one needs to be more careful if using pointers (and trying to make sure the same pointer was not first removed and later re-added). And if you want to optimize the above mentioned cases, one really needs to know if it's true ll+sc, or write the synchronization differently. In these cases the algorithm is often implemented twice with the different available atomics. /Timo