__asm__ __volatile__("": : :"memory");

参考：http://stackoverflow.com/questions/14950614/working-of-asm-volatile-memory

asmvolatile("":::"memory");

creates a compiler level memory barrier forcing optimizer to not re-order memory accesses across the barrier.

For example, if you need to access some address in a specific order (probably because that memory area is actually backed by a different device rather than a memory) you need to be able tell this to the compiler otherwise it may just optimize your steps for the sake of efficiency.

Assume in this scenario you must increment a value in address, read something and increment another value in an adjacent address.

int c(int *d, int *e) {
        int r;
        d[] += ;
        r = e[];
        d[] += ;
        return r;
}

Problem is compiler (gcc in this case) can rearrange your memory access to get better performance if you ask for it (-O). Probably leading to a sequence of instructions like below:

 <c>:
   :           mov r3, r0
   :   c805        ldmia   r0, {r0, r2}
   :           adds    r0, #
   :           adds    r2, #
   :           str r0, [r3, #]
   a:           ldr r0, [r1, #]
   c:   605a        str r2, [r3, #]
   e:           bx  lr

Above values for d[0] and d[1] are loaded at the same time. Lets assume this is something you want to avoid then you need to tell compiler not to reorder memory accesses and that is to use asm volatile("" ::: "memory").

int c(int *d, int *e) {
        int r;
        d[] += ;
        r = e[];
        asm volatile("" ::: "memory");
        d[] += ;
        return r;
}

So you'll get your instruction sequence as you want it to be:

 <c>:
   :           ldr r2, [r0, #]
   :           mov r3, r0
   :           adds    r2, #
   :           str r2, [r0, #]
   :           ldr r0, [r1, #]
   a:   685a        ldr r2, [r3, #]
   c:           adds    r2, #
   e:   605a        str r2, [r3, #]
  :           bx  lr
  :   bf00        nop

It should be noted that this is only compile time memory barrier to avoid compiler to reorder memory accesses, as it puts no extra hardware level instructions to flush memories or wait for load or stores to be completed. CPUs can still reorder memory accesses if they have the architectural capabilities.

This sequence is a compiler memory access scheduling barrier, as noted in the article referenced by Udo. This one is GCC specific - other compilers have other ways of describing them, some of them with more explicit (and less esoteric) statements.

__asm__ is a gcc extension of permitting assembly language statements to be entered nested within your C code - used here for its property of being able to specify side effects that prevent the compiler from performing certain types of optimisations (which in this case might end up generating incorrect code).

__volatile__ is required to ensure that the asm statement itself is not reordered with any other volatile accesses any (a guarantee in the C language).

memory is an instruction to GCC that (sort of) says that the inline asm sequence has side effects on global memory, and hence not just effects on local variables need to be taken into account.