lkml.org 
[lkml]   [2006]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [patch] spinlocks: remove 'volatile'
Date
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
> tnedev@mail.ru

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

\
 
 \ /
  Last update: 2006-07-08 15:49    [W:0.033 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site