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.
> Trajce Nedev
> [email protected]
Thanks,
Chase
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
