From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51202) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Utz8W-0005Eu-Fn for qemu-devel@nongnu.org; Tue, 02 Jul 2013 07:52:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Utz8V-0002vn-H0 for qemu-devel@nongnu.org; Tue, 02 Jul 2013 07:52:44 -0400 Received: from david.siemens.de ([192.35.17.14]:26527) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Utz8V-0002vY-7f for qemu-devel@nongnu.org; Tue, 02 Jul 2013 07:52:43 -0400 Message-ID: <51D2BF03.1060203@siemens.com> Date: Tue, 02 Jul 2013 13:52:35 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <51D29F27.9040706@siemens.com> <51D2B661.3030604@suse.de> <51D2B978.8070903@redhat.com> <51D2BD1D.6010308@siemens.com> <51D2BE47.7070603@redhat.com> In-Reply-To: <51D2BE47.7070603@redhat.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: Paolo Bonzini Cc: Liu Ping Fan , =?ISO-8859-1?Q?Andreas_F=E4rber?= , qemu-devel On 2013-07-02 13:49, Paolo Bonzini wrote: > 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 *im= plements_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 reme= mber >>>> seeing some __sync_* warnings on Mac OS X around 4.2... >>> >>> We are using them already in several places (vhost was the first one = to >>> introduce them, I think, but now they are also in migration ad in som= e >>> tests too). There is no fallback (asm could be a fallback, but we ch= ose >>> to require GCC 4.2 or newer). >>> >>> I'll change this to atomic_inc/dec when applying. Otherwise >> >> 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?). >=20 > 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). Please avoid this ambiguity by naming the functions properly. That xchg returns old values is known, that dec and inc do, is surely not. Jan --=20 Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux