Messages in this thread |  | | | From | Sergei Organov <> | | Subject | Re: [PATCH] Document Linux's memory barriers [try #2] | | Date | Thu, 09 Mar 2006 15:02:15 +0300 |
| |
David Howells <dhowells@redhat.com> writes: [...] > +======================================= > +LINUX KERNEL COMPILER BARRIER FUNCTIONS > +======================================= > + > +The Linux kernel has an explicit compiler barrier function that prevents the > +compiler from moving the memory accesses either side of it to the other side: > + > + barrier(); > + > +This has no direct effect on the CPU, which may then reorder things however it > +wishes. > + > +In addition, accesses to "volatile" memory locations and volatile asm > +statements act as implicit compiler barriers.
This last statement seems to contradict with what GCC manual says about volatile asm statements:
"You can prevent an `asm' instruction from being deleted by writing the keyword `volatile' after the `asm'. [...] The `volatile' keyword indicates that the instruction has important side-effects. GCC will not delete a volatile `asm' if it is reachable. (The instruction can still be deleted if GCC can prove that control-flow will never reach the location of the instruction.) *Note that even a volatile `asm' instruction can be moved relative to other code, including across jump instructions.*"
I think that volatile memory locations aren't compiler barriers either, -- GCC only guarantees that it won't remove the access and that it won't re-arrange the access w.r.t. other *volatile* accesses. On the other hand, barrier() indeed prevents *any* memory access from being moved across the barrier.
-- Sergei.
- 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/
|  |