From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49832) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Utz5U-0002Ml-20 for qemu-devel@nongnu.org; Tue, 02 Jul 2013 07:49:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Utz5S-0001aP-Qf for qemu-devel@nongnu.org; Tue, 02 Jul 2013 07:49:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45388) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Utz5S-0001aL-JP for qemu-devel@nongnu.org; Tue, 02 Jul 2013 07:49:34 -0400 Message-ID: <51D2BE47.7070603@redhat.com> Date: Tue, 02 Jul 2013 13:49:27 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <51D29F27.9040706@siemens.com> <51D2B661.3030604@suse.de> <51D2B978.8070903@redhat.com> <51D2BD1D.6010308@siemens.com> In-Reply-To: <51D2BD1D.6010308@siemens.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] qom: Use atomics for object refcounting List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Liu Ping Fan , =?ISO-8859-1?Q?Andreas_F=E4rber?= , qemu-devel Il 02/07/2013 13:44, Jan Kiszka ha scritto: > On 2013-07-02 13:28, Paolo Bonzini wrote: >> Il 02/07/2013 13:15, Andreas F=E4rber ha scritto: >>>>> @@ -683,16 +683,15 @@ GSList *object_class_get_list(const char *imp= lements_type, >>>>> =20 >>>>> void object_ref(Object *obj) >>>>> { >>>>> - obj->ref++; >>>>> + __sync_fetch_and_add(&obj->ref, 1); >>> How widespread are these in GCC/clang? Is there any fallback? I remem= ber >>> seeing some __sync_* warnings on Mac OS X around 4.2... >> >> We are using them already in several places (vhost was the first one t= o >> introduce them, I think, but now they are also in migration ad in some >> tests too). There is no fallback (asm could be a fallback, but we cho= se >> to require GCC 4.2 or newer). >> >> I'll change this to atomic_inc/dec when applying. Otherwise >=20 > But then atomic_dec_and_test or so. Letting the inc/dec return some > value leaves room for interpretations (value of before or after the > modification?). In qemu, I made all atomic_* functions return the old value. This is consistent with atomic_cmpxchg and atomic_xchg (where returning the new value makes no sense). Paolo