> Damn right. This is the C standard requirement.
> Not all code has Linux-like performance requirements,
> and in any case, standards are standards.
Umm, no it's not a C standard requirement. The C standard requires
'volatile' to work in two specific cases (signals and longjmp) and further
defines certain side-effects of 'volatile' accesses that must not be removed
under any 'as-if' optimizations. GCC fully respects these three
requirements.
For anything else, if you cannot detect it in a compliant program, it is
not a violation of the standard. Programs compliant with the C standard
cannot access shared memory that may be modified by another process nor can
they have multiple threads concurrently executing. So any proposed violation
that can only be exposed under those circumstances is not actually a
violation.
POSIX, for several good reasons, did not extend 'volatile' to provide any
guarantees when used in conjunction with things like 'mmap' and pthreads.
For one thing, it would have added senseless expensive overhead to programs
that used 'volatile' legitimately.
Worse, it would have opened up the atomicity Pandora's box.
It's hard to imagine how 'volatile' could possibly be useful in an SMP
context if it has no atomicity guarantees, and it has no atomicity
guarantees. No standard, as far as I know, has ever expanded 'volatile' to
include atomicity guarantees, so it's totally and completely useless in an
SMP context. So can this argument die now?
DS
-
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]
