Satyam Sharma <[email protected]> wrote:
> In fact you can't really say the same for
> volatile. We already assume the compiler _actually_ took some
> pains to stuff meaning into C's (lack of) definition of volatile and
> implement it -- but in what sense, nobody knows (the C standard
^^^^^^^^^^^^^^
> doesn't, so what are we).
^^^^^^^
It does:
ISO/IEC 9899:1999 (E)
5.1.2.3 Program execution
5 The least requirements on a conforming implementation are:
At sequence points, volatile objects are stable in the sense that previous
accesses are complete and subsequent accesses have not yet occurred.
9 Alternatively, an implementation might perform various optimizations
within each translation unit, such that the actual semantics would agree
with the abstract semantics only when making function calls across
translation unit boundaries. In such an implementation, at the time of each
function entry and function return where the calling function and the
called function are in different translation units, the values of all
externally linked objects and of all objects accessible via pointers
therein would agree with the abstract semantics. Furthermore, at the time
of each such function entry the values of the parameters of the called
function and of all objects accessible via pointers therein would agree
with the abstract semantics. In this type of implementation, objects
referred to by interrupt service routines activated by the signal function
would require explicit specification of volatile storage, as well as other
implementation-defined restrictions.
6.7.3 Type qualifiers
6 An object that has volatile-qualified type may be modified in ways unknown
to the implementation or have other unknown side effects. Therefore any
expression referring to such an object shall be evaluated strictly according
to the rules of the abstract machine, as described in 5.1.2.3. Furthermore,
at every sequence point the value last stored in the object shall agree with
that prescribed by the abstract machine, except as modified by the unknown
factors mentioned previously.114) What constitutes an access to an object
that has volatile-qualified type is implementation-defined.
<snip>
It does not guarantee ordering or consistency beyond the scope of the
assembler layer, especially the CPU or other hardware may be free to cache
or reorder load/stores to these volatile objects (see e.g. MTRR), which is
why you'll usurally want to use something completely different. If you know
an object to not be modified from outside the scope of the C state machine
and it does not have relevant side effects, you can however use volatile
(likely on an atomic value).
I think you should say something like:
1) Don't use volatile
2) Read memory-barriers.txt carefully!
3) If you still use volatile, explain
a) Why it's nescensary
b) Why it's enough (see (2))
to specify volatile on that object. Be sure to consider hardware cache and
reordering, as well as prohibited optimizations on volatile access and on
functions possibly doing volatile access.
--
Top 100 things you don't want the sysadmin to say:
14. Any more trouble from you and your account gets moved to the 750
Friß, Spammer: [email protected] [email protected]
-
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]
