On Thu, Mar 24, 2005 at 11:12:40AM -0500, Christos Zoulas wrote:
> In article <20050324152233.GA18782@antioche.lip6.fr>,
> Manuel Bouyer  <bouyer@antioche.lip6.fr> wrote:
> >Hi,
> >can newer x86 CPUs (hyperthreaded p4 in my case) reorder instructions,
> >or memory writes ? If so, how can we impose barriers ? I didn't find
> >anything obvious in the x86 SMP code, beside bit atomic operations (which
> >don't work in my case).
> >
> >Basically I have these 2 pieces of code in xen (NetBSD and linux), one sender
> >and one receiver, using a piece of shared memory.
> >The receiver:                          |     The sender:
> >                                       |
> >handle_event()                         |     send()
> >{                                      |     {
> >                                       |             a = shared_memory->a;
> >again:                                 |             do_something;
> >        a = shared_memory->a;          |             wmb();
> >        __insn_barrier();              |             shared_memory->a = a + 1;
> >        b = shared_memory->b;          |             mb()
> >        while (b < a) {                |             if (shared_memory->b == a)
> >                /* do something */     |                     send_event();
> >                did_something = 1;     |     }
> >                b++;                   |
> >        }                              |
> >        __insn_barrier();              |
> >        shared_memory->b = b;          |
> >        __insn_barrier();              |
> >        if (did_something)             |
> >                goto again;            |
> >}                                      |
> >
> >The sender is a piece of linux code, mb() and wmb() are both
> >__asm__ __volatile__ ("lock; addl $0,0(%%esp)": : :"memory")
> >which is the same as our x86_lfence(). I tried remplacing __insn_barrier
> >with x86_lfence but the assembly produced by gcc didn't change.
> 
> It did not put:
> 
> #APP
>         lock; addl $0, 0(%esp)
> #NO_APP

Yes, it did. I used gcc -s instead of gcc -S, and so was looking at an older
result :(
sorry everyone for wasting your time.

And remplacing __insn_barrier() with x86_lfence() didn't fix my problem :(

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--