Re: spin_lock forgets to clobber memory and other smp fixes [wasRe: [patch] waitqueue optimization, 2.4.0-test7]

[Andrea Arcangeli <andrea at suse dot de>]

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