from the definition of an "atomic" variable in
the linux kernel,
there are numerous arch-specific header files that define an
atomic
variable in one of two ways:
1) typedef struct { int counter; } atomic_t;
2) typedef struct { volatile int counter; } atomic_t;
the purported need for the "volatile" type
qualifier is to guarantee
that the (gcc) compiler doesn't try to do anything clever
with code
generation, of course, which makes sense.
the problem is that some architectures add the
"volatile" qualifier,
while others don't. but whether it's necessary isn't just
related to
the architecture, is it? wouldn't it be related to just the
properties of the compiler itself?
second, even if an architecture didn't strictly *need*
that
qualifier, would it hurt to have it there? surely having an
unnecessary "volatile" qualifier couldn't break
code that would
otherwise work, could it? it would only prevent some
possible
optimization, no?
and, finally, in some of those header files, even if the
typedef
doesn't use "volatile", some of the function
definitions do:
static inline int atomic_add_return (int i, volatile
atomic_t *v) {
^^^^^^^^
i find this curious. in this particular header file,
while the
typedef doesn't use the type qualifier "volatile",
every routine that
refers to that typedef *does*. would that be considered
equivalent?
that is, would the compiler treat identically the cases
where either
1) the typedef itself has a volatile member, or 2) every
reference is
to a such a typedef which is declared "volatile".
(and on a related
note, would that mean that having "volatile" in
both places would be
utterly redundant? and it would make more sense to just
centralize
that qualifier in a single place, in the typedef?)
thanks.
rday
-
To unsubscribe from this list: send the line
"unsubscribe linux-c-programming" in
the body of a message to majordomo vger.kernel.org
More majordomo info at http://vge
r.kernel.org/majordomo-info.html
|