On Mon, 2014-06-16 at 10:55 +0800, Nor Jaidi Tuah wrote:
Summary: byte access (read/write) is atomic on MOST architectures. Dang! I thought ALL.
I'm not sure but there is no guarantee that it is - you don't know it it will be, say, in ARMv9. Alpha, while probably not in the top 3 most popular ISA on the world, is a strange architecture. Also note the difference between atomicity and synchronization. Most higher level languages exposes "atomics" which are sequentially consistent (in short not only the reads/writes are not 'corrupted' the processor behaves as if they were performed in order they happen in thread). However what some people mean by "atomic" is often much weaker - it just guarantees that value is not corrupted. So aligned loads/stores are atomic in second sense (on most if not all architectures) but not in the first one.
[1] Synchronized means if x and y are set to 0 and thread 1 sets first x and then y to 1 then thread 2 might read y == 1 and then x == 0. Atomic means that state of x and y are either 0 or 1. Note that x86 is rather strongly order architecture so you won't notice it in _most_ circumstances on that platform but you can get the reordering on for example arm. Programmers manual from processors should have a few pages in them stating the exact rules.Don't forget the compiler. It too can reorder.
Well. That's the only reordering that volatile is suppose to prevent. I.e. if stores to volatile happens in x y order in code they happen in x y code in assembly. For example imagine printer controller - reversing those statements would have different effect[1]. # Location in memory where the page is located registers[print_page_buffer] = ptr # Do print contents registers[print_do_print] = 1 However that's true - compiler do reorder the code as well as happily breakes a perfectly 'fine' code that was supposed to work[2]. Best regards [1] Memory mapped I/O are in uncached memory as specified by page table/control registers/<insert method from processor manual here> so the question about cache hierarchy and processor reordering do not play a role here as processor already knows it's not suppose to reorder for this memory. [2] http://blog.regehr.org/archives/918
Attachment:
signature.asc
Description: This is a digitally signed message part