From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49856) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sz69l-0008Tc-7p for qemu-devel@nongnu.org; Wed, 08 Aug 2012 09:18:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sz69f-0002qH-GK for qemu-devel@nongnu.org; Wed, 08 Aug 2012 09:18:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33889) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sz69f-0002q9-6Z for qemu-devel@nongnu.org; Wed, 08 Aug 2012 09:18:31 -0400 Message-ID: <5022671E.8070602@redhat.com> Date: Wed, 08 Aug 2012 15:18:22 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1344407156-25562-1-git-send-email-qemulist@gmail.com> <1344407156-25562-2-git-send-email-qemulist@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 01/15] atomic: introduce atomic operations List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Peter Maydell , kvm@vger.kernel.org, Jan Kiszka , Marcelo Tosatti , Liu Ping Fan , qemu-devel@nongnu.org, Blue Swirl , Avi Kivity , Anthony Liguori , =?ISO-8859-1?Q?Andreas_F=E4rber?= Il 08/08/2012 15:09, Stefan Hajnoczi ha scritto: >> > NAK. We don't want random inline assembly implementations of locking >> > primitives in QEMU, they are way too hard to keep working with all the >> > possible host architectures we support. I spent some time a while back >> > getting rid of the (variously busted) versions we had previously. >> > >> > If you absolutely must use atomic ops, use the gcc builtins. For >> > preference, stick to higher level and less error-prone abstractions. > We're spoilt for choice here: > > 1. Atomic built-ins from gcc > 2. glib atomics > > No need to roll our own or copy the implementation from the kernel. To some extent we need to because: 1. GCC atomics look ugly, :) do not provide rmb/wmb, and in some versions of GCC mb is known to be (wrongly) a no-op. 2. glib atomics do not provide mb/rmb/wmb either, and g_atomic_int_get/g_atomic_int_set are inefficient: they add barriers everywhere, while it is clearer if you put barriers manually, and you often do not need barriers in the get side. glib atomics also do not provide xchg. I agree however that a small wrapper around GCC atomics is much better than assembly. Assembly can be limited to the memory barriers (where we already have it anyway). Paolo