Chase Venters <[email protected]> writes:
> You're mincing my words. The reason "memory" is on the clobber list is
> because
> a lock is supposed to synchronize all memory accesses up to that point. It's
> a fence / a barrier, because if the compiler re-orders your loads/stores
> across the lock, you're in trouble. That's exactly what I was pointing out.
Sure, but a barrier alone isn't enough. You have to use assembler and
it's beyond scope of C volatile.
> A volatile cast lets you prevent the compiler from always treating the
> variable as volatile.
Yes, if that's what you really want.
>> If the "volatile" is used the wrong way (which is probably true for most
>> cases), then volatile cast and barrier() will be wrong as well. You need
>> locks or atomic access, meaningful on hardware level.
>
> No. Linus already described what some example invalid uses of "volatile"
> are.
> One example is the very one this whole thread is about - using 'volatile' on
> the declaration of the spinlock counter. That usage is _wrong_, and
> barrier()
> would not be.
That's a special case, because you want to invalidate all variables,
but you still need locking. I.e., barrier() alone doesn't buy you
anything WRT to hardware.
> Volatile originally existed to tell the compiler a variable could change at
> will. Because of reordering, it's almost never sufficient with our modern
> compilers and CPUs. That's precisely where barrier() (and/or its hardware
> equivalents) help in places where 'volatile' is wrong.
How does barrier() help here? Some example, maybe?
What do you consider a barrier() hardware equivalent?
Don't you think you're mixing compiler optimization and operation of
the hardware?
> Your statement is
> additionally wrong because one use-case of memory barriers is to safely
> write
> lock-free code.
You can't safely write lock-free code in C, if you have to deal
with hardware or SMP. C don't know about hardware.
--
Krzysztof Halasa
-
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]
