On 10/05/07, Satyam Sharma <[email protected]> wrote:
On 5/10/07, Jesper Juhl <[email protected]> wrote:
> On 09/05/07, Jonathan Corbet <[email protected]> wrote:
<snip>
> > +"the new C book") has the following to say about the volatile keyword:
> > +
> > + The purpose of volatile is to force an implementation to suppress
> > + optimization that could otherwise occur. For example, for a
> > + machine with memory-mapped input/output, a pointer to a device
> > + register might be declared as a pointer to volatile, in
> > + order to prevent the compiler from removing apparently redundant
> > + references through the pointer.
> > +
> > +C programmers have often taken volatile to mean that the variable could be
> > +changed outside of the current thread of execution; as a result, they are
>
> you write: "... that the variable could be changed outside of the
> current thread of execution ..."
>
> I suggest: "... that the variable could be changed outside of the
> current thread of execution - a sort of simple atomic variable ..."
I'm not so sure here. Why would any C programmer (worth his weight in
salt) think that volatile objects are automatically _atomic_? At
I honestly don't really know, but I've encountered that confusion a
few times. Both from friends who (for some reason) believed that and
from documents on the web that implied it, aparently it's a common
confusion - a few examples:
http://lists.freebsd.org/pipermail/freebsd-perl/2004-June/000124.html
"... volatile (atomic) fixes the problem. ..."
http://blogs.msdn.com/ricom/archive/2006/04/28/586406.aspx
"That's the point of the volatile keyword. It makes sure that
the line "dict = d;" is atomic."
http://forum.java.sun.com/thread.jspa?threadID=5126877&start=0
"A volatile variable is also guaranteed to be read or written
as an atomic operation ..." (yes, this link talks about Java, which I
don't know, but if java volatile means atomic, that might explain why
some people assume the same for C).
In any case, it's not an uncommon belief, so I just thought it made
sense to also make that little note.
worst, the mistake someone might make would be to _implement_ locking
primitives using volatile. "that the variable could be changed outside
of the current thread of execution" sounds sufficient to me, and after
all, that is exactly what volatile hints to the compiler.
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
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]
