[ltt-dev] [PATCH] fix the "unknown" case

[paulmck@linux.vnet.ibm.com (Paul E. McKenney)]

On Tue, Jun 15, 2010 at 02:35:16PM +0200, Ulrich Weigand wrote:
> "Paul E. McKenney" <paulmck at linux.vnet.ibm.com> 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
>