Re: [patch] spinlocks: remove 'volatile'

["Chris Friesen" <cfriesen@nortel.com>]

Linus Torvalds wrote:
> On Thu, 6 Jul 2006, Chris Friesen wrote:
>
> > The C standard requires the use of volatile for signal handlers and setjmp.
>
>
> Actually, the C standard requires "sigatomic_t".


From ISO/IEC 9899:TC2, both of these specifically mention volatile:


7.13.2.1 The longjmp function

3 All accessible objects have values, and all other components of the 
abstract machine212) have state, as of the time the longjmp function was 
called, except that the values of objects of automatic storage duration 
that are local to the function containing the invocation of the 
corresponding setjmp macro that do not have volatile-qualified type and 
have been changed between the setjmp invocation and longjmp call are 
indeterminate.


7.14.1.1 The signal function

5 If the signal occurs other than as the result of calling the abort or 
raise function, the behavior is undefined if the signal handler refers 
to any object with static storage duration other than by assigning a 
value to an object declared as volatile sig_atomic_t, ...


> > For userspace at least the whole discussion of "barriers" is sort of
> > moot--there are no memory barriers defined in the C language, which makes it
> > kind of hard to write portable code that uses them.
>
>
> Any locking primitive BY DEFINITION has a barrier in it.
>
> If it doesn't, it's not a locking primitive, it's a random sequence of 
> code that does something pointless.

Sure, so the implementation of the locking primitives requires 
hardware-specific knowledge.

But for someone coding to POSIX, is there any reason why they would use 
barriers?  If so, what API would they use?

Chris
-
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/