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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
