| |||||||||||||
Betrayed by a bitfieldBetrayed by a bitfieldPosted Feb 6, 2012 21:04 UTC (Mon) by dlang (✭ supporter ✭, #313)In reply to: Betrayed by a bitfield by chrisV Parent article: Betrayed by a bitfield
one of the posts I saw on this topic (I think from Linus) tested the code snippet
volitile int a;
b++;
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.
(Log in to post comments)
Betrayed by a bitfield Posted Feb 6, 2012 21:16 UTC (Mon) by chrisV (subscriber, #43417) [Link]
"no, the item in question wasn't related to interrupts, but the cause of the problem causes the same problem if interrupts were involved."
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.
|
|||||||||||||