Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures

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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Named shared memory without synchronization
    ... A primitive lives in a shared memory page. ... width of the CPU register, ... compiler doesn't need the volatile declaration. ...
    (microsoft.public.vc.language)
  • Re: Starting to doubt fortran
    ... with a mechanical typewriter (Teletype model 33 comes to mind) ... to either register and memory; it also had preinc and postdec ... addressing modes which combined increment and decrement of a pointer, ... PDP-10 had both add memory to register and add ...
    (comp.lang.fortran)
  • Re: volatile and multiple threads
    ... such that reading a register fetches the "next" input value. ... you don't want the compiler optimizing away ... If the memory address isn't ... ting systems will use volatile. ...
    (comp.lang.c)
  • Re: [Multi-Threading] Instruction Re-Ordering
    ... register, hence an oter thread accessing the variable might not see any ... while volatile was created to address this issue by making the code always ... access the memory it's not enough as ... >> the write instruction in the instruction sequence (see ...
    (microsoft.public.dotnet.framework)
  • Re: Proper Use of Volatile?
    ... I'm not quite sure when I should use volatile. ... The compiled code must actually perform ... A loop that polls a volatile device register until the READY bit ... forces it to be read from memory whenever it's inspected. ...
    (comp.lang.c)
Loading