Messages in this thread | | | From | Segher Boessenkool <> | Subject | Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures | Date | Tue, 21 Aug 2007 00:04:17 +0200 |
| |
>> Right. ROTFL... volatile actually breaks atomic_t instead of making >> it safe. x++ becomes a register load, increment and a register store. >> Without volatile we can increment the memory directly. It seems that >> volatile requires that the variable is loaded into a register first >> and then operated upon. Understandable when you think about volatile >> being used to access memory mapped I/O registers where a RMW >> operation could be problematic. > > So, if we want consistent behavior, we're pretty much screwed unless > we use inline assembler everywhere?
Nah, this whole argument is flawed -- "without volatile" we still *cannot* "increment the memory directly". On x86, you need a lock prefix; on other archs, some other mechanism to make the memory increment an *atomic* memory increment.
And no, RMW on MMIO isn't "problematic" at all, either.
An RMW op is a read op, a modify op, and a write op, all rolled into one opcode. But three actual operations.
The advantages of asm code for atomic_{read,set} are: 1) all the other atomic ops are implemented that way already; 2) you have full control over the asm insns selected, in particular, you can guarantee you *do* get an atomic op; 3) you don't need to use "volatile <data>" which generates not-all-that-good code on archs like x86, and we want to get rid of it anyway since it is problematic in many ways; 4) you don't need to use *(volatile <type>*)&<data>, which a) doesn't exist in C; b) isn't documented or supported in GCC; c) has a recent history of bugginess; d) _still uses volatile objects_; e) _still_ is problematic in almost all those same ways as in 3); 5) you can mix atomic and non-atomic accesses to the atomic_t, which you cannot with the other alternatives.
The only disadvantage I know of is potentially slightly worse instruction scheduling. This is a generic asm() problem: GCC cannot see what actual insns are inside the asm() block.
Segher
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |