Re: [patch] spinlocks: remove 'volatile'

[Steven Rostedt]

On Sat, 2006-07-08 at 08:46 -0500, Chase Venters wrote:
> On Saturday 08 July 2006 01:44, trajce nedev wrote:
> > On Sat, 8 Jul 2006, Chase Venters wrote:
> > >Perhaps you should have followed this thread closely before composing your
> > >assault on Linus. We're not talking about "asm volatile". We're talking
> > >about
> > >the "volatile" keyword as applied to variables. 'volatile' as applied to
> > >inline ASM is of course necessary in many cases -- no one is disputing
> > >that.
> >
> > Ok, let's port a spinlock macro that spins instead of context switches
> > instead of using the pthread garbage on IA64 or AMD64:
> >
> > #if ((defined (_M_IA64) || defined (_M_AMD64)) && !defined(NT_INTEREX))
> > #include <windows.h>
> > #pragma intrinsic (_InterlockedExchange)
> >
> > typedef volatile LONG lock_t[1];
> >
> > #define LockInit(v)	((v)[0] = 0)
> > #define LockFree(v)	((v)[0] = 0)
> > #define Unlock(v)	((v)[0] = 0)
> >
> > __forceinline void Lock(volatile LONG *hPtr)
> > {
> > 	int iValue;
> >
> > 	for (;;) {
> > 		iValue = _InterlockedExchange((LPLONG)hPtr, 1);
> > 		if (iValue == 0)
> > 			return;
> > 		while (*hPtr);
> > 	}
> > }
> >
> > Please show me how I can write this to spinlock without using volatile.
> 
> Please show me how that lock is safe without a compiler memory barrier! What's 
> to stop your compiler from moving loads and stores across your inlined lock 
> code?
> 
> When you add the missing compiler memory barrier, the "volatile" classifier 
> becomes unnecessary.
> 
> Actually, please just read the thread. We've been over this already. It's 
> starting to get really old.

Actually it was good that he posted.  It just proved Linus's assumption
that those that use volatile usually don't understand exactly what is
going on.  I certainly learned a lot in this thread ;)

[ /me goes off to fix some of my broken "volatile" code ... ]

-- Steve


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/