Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Betrayed by a bitfield
Posted Feb 6, 2012 20:01 UTC (Mon) by chrisV (subscriber, #43417)
This is orthogonal to the original problem, which (as far as I can work out) is concerned with concurrent access by different threads.
Posted Feb 6, 2012 20:06 UTC (Mon) by dlang (✭ supporter ✭, #313)
As Linux says, it's possible for someone to fix the bug with respect to volatile, and explicitly leave the bug in for all other accesses (with the claim that the spec allows the compiler to do that), but it would probably be more work to do that then to just change the behaviour across the board.
Posted Feb 6, 2012 20:51 UTC (Mon) by chrisV (subscriber, #43417)
I don't believe that has been tested and I don't believe it to be true. On hardware where 64 bit boundaries are important, sig_atomic_t would be likely to be 64-bits wide. (Someone with a ia64 architecture might be able to confirm this.) In that case alignment boundaries would be fully respected.
Also, I can't see that the original problem had anything to do with interrupts. It seems to be concerned with either multi-threading, or shared access by multiple processes.
Lastly, when you refer to "the bug with respect to volatile", you impute that gcc has the bug. If there is a bug, it is a bug in the kernel.
Posted Feb 6, 2012 21:04 UTC (Mon) by dlang (✭ supporter ✭, #313)
volitile int a;
and the resulting assembler did the exact same read-write on a that caused the problem with the case in question. If an interrupt were to happen between the read and the write that changed the value of a, the write would cause that value to be lost.
no, the item in question wasn't related to interrupts, but the cause of the problem causes the same problem if interrupts were involved.
If the 32 bit loads and stores were significantly more expensive to use than 64 bit loads and stores, there would be at least some reason to have this behaviour available, but in the case of the architectures in question there isn't a performance benefit to doing it this way.
Posted Feb 6, 2012 21:16 UTC (Mon) by chrisV (subscriber, #43417)
Not it doesn't. Memory access issues relating to multiple threads (or multiple processes in the case of shared memory) have nothing to do with interrupts, and nothing to do with volatile.
This really is beating a dead horse. Compiler switches are available to ensure memory consistency for the case in question, notably the -pthread switch. I can see why the kernel doesn't want to, or can't, use that. In that case the kernel authors need to write some assembler or use 64-bit values on architectures where it is important, or persuade the gcc developers to provide another compiler switch dealing with this particular problem.
Posted Feb 6, 2012 20:05 UTC (Mon) by daglwn (subscriber, #65432)
Posted Feb 6, 2012 20:13 UTC (Mon) by dlang (✭ supporter ✭, #313)
again the code snippit is
if modifying b causes a read/write of a, this is wrong.
the programmer has not made any attempt to specify alignment here.
Posted Feb 7, 2012 0:48 UTC (Tue) by daglwn (subscriber, #65432)
No, it's not. Believe me.
The volatile keyword doesn't say anything about when it will change value, be read/written etc. It says simply that it will not be cached in a register such that every read will get the "latest" value expected when executed under the Abstract Machine.
It says nothing about threading.
It says nothing about interrupts.
Simply remember that volatile is not magic. Think of it as the opposite of "register."
Posted Feb 7, 2012 1:03 UTC (Tue) by dlang (✭ supporter ✭, #313)
since this sort of thing has been part of C's traditional strength, this doesn't seem like a sane interpretation to me.
Posted Feb 7, 2012 16:54 UTC (Tue) by chrisV (subscriber, #43417)
I think it does. See §22.214.171.124/5 and /10, which are normative. The principal purpose of volatile is to deal with arbitrary changes of data values outside the program context of the process in which the code is running (ie asynchronous interrupts). (This does not include threads, which are within the program context and which, because they can run on more than one core, require quite different synchronizations, some of which are not async-signal-safe.)
See also the footnote 134 of §6.7.3/8 (which is non-normative despite the "shall not"): "A volatile declaration may be used to describe an object corresponding to a memory-mapped input/output port or an object accessed by an asynchronously interrupting function. Actions on objects so declared shall not be 'optimized out' by an implementation or reordered except as permitted by the rules for evaluating expressions." This is a curious note as, as far as I am aware, it is the one and only reference to memory mapping (and about which I mis-spoke in an earlier posting on this article because it is not in C99 which contains no reference to memory mapping).
Posted Feb 7, 2012 18:38 UTC (Tue) by daglwn (subscriber, #65432)
Thanks for the correction. But the compiler is still correct here. Volatile doesn't say anything about restricting _when_ it is read or written, only that it will get the "latest" value in a single-thread context.
It's perfectly fine for I/O as long as you can guarantee alignment such that there is no "false sharing."
Posted Feb 7, 2012 19:07 UTC (Tue) by chrisV (subscriber, #43417)
Posted Feb 7, 2012 20:01 UTC (Tue) by dlang (✭ supporter ✭, #313)
Posted Feb 7, 2012 23:32 UTC (Tue) by daglwn (subscriber, #65432)
No, there isn't.
There isn't. Really.
Volatile does not mean what you think it means.
It's a bit like sequential consistency. Just when you think you understand it, something unexpected happens that is both non-intuitive and perfectly legal.
Posted Feb 8, 2012 15:24 UTC (Wed) by daglwn (subscriber, #65432)
Posted Feb 8, 2012 13:51 UTC (Wed) by nix (subscriber, #2304)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds