From mboxrd@z Thu Jan 1 00:00:00 1970 From: paulmck@linux.vnet.ibm.com (Paul E. McKenney) Date: Tue, 15 Jun 2010 08:07:27 -0700 Subject: [ltt-dev] [PATCH] fix the "unknown" case In-Reply-To: References: <20100614220600.GA15130@linux.vnet.ibm.com> Message-ID: <20100615150727.GC2304@linux.vnet.ibm.com> On Tue, Jun 15, 2010 at 02:35:16PM +0200, Ulrich Weigand wrote: > "Paul E. McKenney" wrote on 06/15/2010 > 12:06:00 AM: > > > When I use __sync_synchronize(), I get failures from the > rcutorture_urcu_mb > > stress test. When I use a "dmb" instruction, I don't get any failures. > > > > No idea why, to be honest. > > If you get the code as below for __sync_synchronize, that's no wonder: this > code is a plain compiler optimization barrier, it does not have any > hardware > memory barrier at all ... That would explain it! ;-) > > int > > f() > > { > > __sync_synchronize(); > > } > [snip] > > str fp, [sp, #-4]! > > add fp, sp, #0 > > add sp, fp, #0 > > ldmfd sp!, {fp} > > bx lr > > No hardware barrier instruction ... > > > (insn 5 4 14 3 sync_sync.c:4 (parallel [ > > (asm_operands/v ("") ("") 0 [] > > [] 477) > > (clobber (mem:BLK (scratch) [0 A8])) > > ]) -1 (nil)) > > ... as this is just a optimization barrier here. > > Looking at the compiler sources, the __sync_synchronize call gets > translated into: > > a. a hardware memory barrier instruction if provided by the platform > b. otherwise, a call to a __sync_synchronize libgcc routine if provided > by the platform > c. otherwise, just a compiler optimization barrier > > On ARM (at least on GCC mainline), there is no memory barrier hardware > instruction defined in the backend, so you'll never get a. > > There *is* support for b., i.e. a call to a library func, but only if > you're using a quite recent compiler. Support was added to mainline > on 2009-08-12; the first official GCC release to contain the change > is 4.5.0; the change was later backported to 4.4.3. (As you seem to > be using 4.4.1, this feature is probably just not there yet.) Thank you very much for looking into this and for the information! > See also the discussion in this bugzilla and the mailing list threads > linked from it: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42263 So I cannot expect the other __sync_ primitives to be generate memory barriers, either, correct? Hmmm... From looking at http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00198.html, I wonder whether I can rely on them to be using atomic instructions -- though I do admit that __sync_lock_release() often does not need an atomic instruction. So, should I just bite the bullet and write the usual set of asms myself? People are going to want to build liburcu on old compilers, sad to say... Thanx, Paul > Mit freundlichen Gruessen / Best Regards > > Ulrich Weigand > > -- > Dr. Ulrich Weigand | Phone: +49-7031/16-3727 > STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. > IBM Deutschland Research & Development GmbH > Vorsitzender des Aufsichtsrats: Martin Jetter | Gesch?ftsf?hrung: Dirk > Wittkopp > Sitz der Gesellschaft: B?blingen | Registergericht: Amtsgericht > Stuttgart, HRB 243294 >