http://bugzilla.gdcproject.org/show_bug.cgi?id=126
--- Comment #9 from Johannes Pfau <johannesp...@gmail.com> --- @Mike: AFAIK shared has some additional requirements which are not necessary for volatile: 1.) Atomic access: Accessing shared variables must always use atomic access (This is not yet enforced, but see https://github.com/D-Programming-Language/dmd/pull/3070) 2.) Accessing shared variables should also prevent reordering by the CPU (I'm not 100% sure about this though), not only by the compiler, as volatile does. I guess in the end shared variables will always be accessed via some function (atomicOp, synchronized statement + casting, ...). Also shared variables could ignore requirement 1. At least in C++/11 multiple accesses to atomics can be merged (http://stackoverflow.com/a/6681505/471401). Regarding peek/poke functions: Don't you think that's too cumbersome? I also think shared + peek/poke has the drawback that you can still accidentally access it like a normal shared variable, without the peek/poke guarantees. I'd prefer introducing a volatile type qualifier that enforces only one property: The compiler does not optimize access but we don't guarantee anything about the actual execution on hardware. Volatile memory also sometimes has properties which don't match traditional memory: I think I've seen architectures where reading a register might return a completely different value than the value written in a previous write. Most functions dealing with 'standard' memory will produce incorrect results if they operate on such memory. By using an additional 'volatile' type qualifier we can make sure that only functions which explicitly accept volatile memory can be used with volatile variables. BTW: I finally finished the volatile DIP, see http://wiki.dlang.org/DIP62 . It'd be great to get some early feedback from you and Iain, and feel free to edit the DIP :-) -- You are receiving this mail because: You are watching all bug changes.
