From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48799) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b2qNp-00055M-IB for qemu-devel@nongnu.org; Tue, 17 May 2016 21:34:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b2pLe-00035L-LU for qemu-devel@nongnu.org; Tue, 17 May 2016 20:28:29 -0400 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:33486) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b2pLc-00034N-7E for qemu-devel@nongnu.org; Tue, 17 May 2016 20:28:26 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id AFF0E20A8C for ; Tue, 17 May 2016 20:28:14 -0400 (EDT) Date: Tue, 17 May 2016 20:28:14 -0400 From: "Emilio G. Cota" Message-ID: <20160518002814.GA25803@flamenco> References: <1463196873-17737-1-git-send-email-cota@braap.org> <1463196873-17737-8-git-send-email-cota@braap.org> <573B5134.8060104@gmail.com> <66d14198-dab0-c72e-fe17-d022cff3feff@twiddle.net> <20160517200415.GD30174@flamenco> <573B7CFB.30002@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <573B7CFB.30002@gmail.com> Subject: Re: [Qemu-devel] [PATCH v5 07/18] qemu-thread: add simple test-and-set spinlock List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sergey Fedorov Cc: Richard Henderson , QEMU Developers , MTTCG Devel , Alex =?iso-8859-1?Q?Benn=E9e?= , Paolo Bonzini , Peter Crosthwaite On Tue, May 17, 2016 at 23:20:11 +0300, Sergey Fedorov wrote: > On 17/05/16 23:04, Emilio G. Cota wrote: (snip) > > +/* > > + * We might we tempted to use __atomic_test_and_set with __ATOMIC_ACQUIRE; > > + * however, the documentation explicitly says that we should only pass > > + * a boolean to it, so we use __sync_lock_test_and_set, which doesn't > > + * have this limitation, and is documented to have acquire semantics. > > + */ > > +#define atomic_test_and_set_acquire(ptr) __sync_lock_test_and_set(ptr, true) > > So you are going to stick to *legacy* built-ins? Why not? AFAIK the reason to avoid __sync primitives is that in most cases they include barriers that callers might not necessarily need; __atomic's allow for finer tuning, which is in general a good thing. However, __sync_test_and_set has the exact semantics we need, without the limitations documented for __atomic_test_and_set; so why not use it? E.