From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35560) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b32JO-0003pC-IK for qemu-devel@nongnu.org; Wed, 18 May 2016 10:18:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b32JJ-0000c0-DN for qemu-devel@nongnu.org; Wed, 18 May 2016 10:18:57 -0400 Received: from mail-lb0-x241.google.com ([2a00:1450:4010:c04::241]:34512) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b32JJ-0000bg-53 for qemu-devel@nongnu.org; Wed, 18 May 2016 10:18:53 -0400 Received: by mail-lb0-x241.google.com with SMTP id bg8so2833213lbc.1 for ; Wed, 18 May 2016 07:18:53 -0700 (PDT) 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> <20160518002814.GA25803@flamenco> From: Sergey Fedorov Message-ID: <573C79CA.3010703@gmail.com> Date: Wed, 18 May 2016 17:18:50 +0300 MIME-Version: 1.0 In-Reply-To: <20160518002814.GA25803@flamenco> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: "Emilio G. Cota" Cc: Richard Henderson , QEMU Developers , MTTCG Devel , =?UTF-8?Q?Alex_Benn=c3=a9e?= , Paolo Bonzini , Peter Crosthwaite On 18/05/16 03:28, Emilio G. Cota wrote: > 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? So it should be okay as long as the legacy build-ins are supported. Kind regards, Sergey