Messages in this thread |  | | Date | Thu, 7 Sep 2000 19:02:18 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: spin_lock forgets to clobber memory and other smp fixes [was Re: [patch] waitqueue optimization, 2.4.0-test7] |
| |
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>Interestingly enough, the local variable case is one where "memory" does >make a difference. Without "memory": > > movl p, %eax > movl (%eax), %eax >#APP >#NO_APP > >With "memory": > >#APP >#NO_APP > movl p, %eax > movl (%eax), %eax
My gcc doesn't make differences between "memory" and non "memory" in this testcase:
int * p;
extern f(int);
main() { int a;
a = *p; __asm__ __volatile__("zzz" : :);
a = *p;
f(a); }
My compiler _always_ produced first the zzz and then it loads p (regardless of "memory" clobber or not). That's why I said I couldn't reproduce miscompilations.
>As you can see from above, there are cases where > > local_var = shared->mumble; > // ... ^^^^^^ > spin_lock (&spinlock); > local_var = shared->mumble; > >requires a "memory" clobber, otherwise the second read, which is in a >critical region, won't be emitted by the compiler.
In your testcase have only `//' in the underlined line, so the compiler is 100% allowed to throw away the first read to local_val, so far so good.
So the compiler does only one read from the `p' pointer and on with my compiler it's always done _after_ the spin_lock (or after the __asm__ __volatile__ in the above testcase).
Of course "memory" should enforce the read to be done after the spin_lock but in real life it seems to do the right thing anyway and I couldn't reproduce miscompilation.
Said that if your compiler puts the read before the spin_lock without the memory clobber, it is allowed to do that, and in such case you would proof it was a real world bug (not just a "documentation" one).
Or maybe your testcase was a bit different then mine, in such case please send it to me (I'm curious indeed :).
Andrea
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |